mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 22:15:20 +00:00
Code Issues Releases Wiki Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2001-01-04 19:14:47 +00:00
parent 3b5102fc01
commit 99b792d88b
3 changed files with 253 additions and 233 deletions
Download Patch File Download Diff File Expand all files Collapse all files

240
doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt → doc/draft/draft-ietf-dnsext-dnssec-roadmap-01.txt
View File

@@ -6,7 +6,7 @@
DNEXT Working Group S. Rose
Internet Draft NIST
Expires: February 2001 August 2000
Expires: June 2001 January 2001
Category: Informational
@@ -14,7 +14,7 @@ Category: Informational
DNS Security Document Roadmap
------------------------------
<draft-ietf-dnsext-dnssec-roadmap-00.txt>
<draft-ietf-dnsext-dnssec-roadmap-01.txt>
Status of this Document
@@ -61,7 +61,7 @@ Rose [Page 1]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
INTERNET-DRAFT DNS Security Document Roadmap January 2001
find in which document and author guidelines for what to
@@ -72,8 +72,7 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
Table of Contents
1. Introduction ............................................... 3
@@ -121,7 +120,7 @@ Rose [Page 2]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
INTERNET-DRAFT DNS Security Document Roadmap January 2001
1. Introduction
@@ -181,7 +180,7 @@ Rose [Page 3]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
INTERNET-DRAFT DNS Security Document Roadmap January 2001
possible that some documents fall into more than one of these
@@ -206,9 +205,13 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
| Security | <------->| protocol |<-------->| Security |
| RRs | | | | Uses |
| [RFC2538, | | [RFC2535, | | |
| SIG0 NO] | | CLARIFY, | +-------------+
+------------+ | AUTH, |
| RFC2931, | | RFC3007, | +-------------+
| NO] | | RFC3008, |
+------------+ | CLARIFY, |
| SIZE ] |
| OKBIT, |
| ADBIT, |
| OPTIN ] |
+-----------+
|
|
@@ -219,19 +222,15 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
| DS | | | | Implementation |
| Algorithm | | Transactions | * Notes *
| Impl. | | | | |
| [RFC2536, | | [RFC2845, | * [CAIRN] *
| RFC2537 | | TKEY] | | |
| [RFC2536, | | [RFC2845, | * [CAIRN, *
| RFC2537 | | RFC2930] | | ROLLOVER ] |
| RFC2539 | | | * *
| GSS-TSIG] | | | +-*-*-*-*-*-*-*-*-+
+------------+ +---------------+
| GSS-TSIG, | | | +-*-*-*-*-*-*-*-*-+
| RSA-SHA] | +---------------+
+------------+
Figure 1 DNSSEC Document Roadmap
The "DNSSEC protocol" document set refers to the document that makes
up the groundwork for adding security to the DNS protocol [RFC2535]
and updates to this document. RFC 2535 laid out the goals and expec-
tations of DNS Security and the new security related Resource Records
KEY, SIG, and NXT. Expanding from this document, related document
@@ -241,9 +240,14 @@ Rose [Page 4]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
INTERNET-DRAFT DNS Security Document Roadmap January 2001
The "DNSSEC protocol" document set refers to the document that makes
up the groundwork for adding security to the DNS protocol [RFC2535]
and updates to this document. RFC 2535 laid out the goals and expec-
tations of DNS Security and the new security related Resource Records
KEY, SIG, and NXT. Expanding from this document, related document
groups include the implementation documents of various digital signa-
ture algorithms with DNSSEC, and documents further refining the tran-
saction of messages. It is expected that RFC 2535 will be obseleted
@@ -254,21 +258,21 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
lines of RFC/Internet Draft author guidelines). Also, the portions
of the specification to be modified SHOULD be synopsized in the new
document for the benefit of the reader. The "DNSSEC protocol" set
includes the documents [RFC2535], [CLARIFY], [AUTH], [SIZE] and their
derivative documents.
includes the documents [RFC2535], [RFC3007], [RFC3008], [CLARIFY],
[SIZE], [OKBIT], [ADBIT] and their derivative documents.
The "New Security RRs" set refers to the group of documents that seek
to add additional Resource Record to the set of base DNS Record
types. These new records can be related to securing the DNS protocol
[RFC2535] [SIG0] [NO] or using DNS security for other purposes such
as storing certificates [RFC2538].
[RFC2535], [RFC2931], [NO] or using DNS security for other purposes
such as storing certificates [RFC2538].
The "DS Algorithm Impl" document set refers to the group of documents
that describe how a specific digital signature algorithm is imple-
mented to fit the DNSSEC Resource Record format. Each one of these
documents deals with one specific digital signature algorithm. Exam-
ples of this set include [RFC2536] [RFC2537] [RFC2539] and [GSS-
TSIG].
ples of this set include [RFC2536], [RFC2537], [RFC2539], [RSA-SHA]
and [GSS-TSIG].
The "Transactions" document set refers to the group of documents that
deal with the message transaction sequence of security related DNS
@@ -276,7 +280,7 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
update [RFC2137] [UPDATE] and transaction signatures [RFC2845] are
described in this document category. Additional message transaction
schemes to support DNSSEC operation would also fall under this group,
including secret key establishment [TKEY], and verification.
including secret key establishment [RFC2930], and verification.
The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
@@ -287,11 +291,6 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
Lastly, there is a set of documents that should be classified as
"Implementation Notes". Because the DNS security extensions are
still in the developmental stage, there is an audience for documents
that detail the transition and implementation of the security exten-
sions. These have more to do with the practical side of DNS opera-
tions, but can also point to places in the protocol specifications
that need improvement. Documents in this set may be offspring of
both the DNSEXT and/or DNSOP working groups. Currently, there is
@@ -301,17 +300,25 @@ Rose [Page 5]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
INTERNET-DRAFT DNS Security Document Roadmap January 2001
only one Internet Draft that falls under this category: The report
on the CAIRN DNSSEC testbed [CAIRN]. This document was submitted
through the DNSOP working group, however the main concern of this
document in the implementation and limitations of the DNS security
extensions, hence its interest to the DNS security community.
Authors of documents that deal with the implementation and opera-
tional side of the DNSSEC specifications would be advised/encouraged
to submit their documents to the DNSEXT working group as well.
that detail the transition and implementation of the security exten-
sions. These have more to do with the practical side of DNS opera-
tions, but can also point to places in the protocol specifications
that need improvement. Documents in this set may be offspring of
both the DNSEXT and/or DNSOP working groups. Currently, there are
two Internet Drafts that falls under this category: The report on
the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
[ROLLOVER]. These documents were submitted through the DNSOP working
group, however the main concern of these documents is the implementa-
tion and limitations of the DNS security extensions, hence their
interest to the DNS security community. The CAIRN draft deals with
the implementation of a secure DNS, and the draft on key rollover
deals with updating DNS keys in a secure fashion. Authors of docu-
ments that deal with the implementation and operational side of the
DNSSEC specifications would be advised/encouraged to submit their
documents to the DNSEXT working group as well.
3. Relationship of DNS Security Documents to other DNS Documents
@@ -345,14 +352,6 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
the contents of any DNS extension document.
4.1 Security Related Resource Records
Documents describing a new type of DNS Security Resource Record (RR)
should contain information describing the structure and use of the
new RR type. It is a good idea to only discuss one new type in a
document, unless the set of new resource records are closely related
or a protocol extensions requires the use of more than one new record
Rose [Page 6]
@@ -361,9 +360,16 @@ Rose [Page 6]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
INTERNET-DRAFT DNS Security Document Roadmap January 2001
4.1 Security Related Resource Records
Documents describing a new type of DNS Security Resource Record (RR)
should contain information describing the structure and use of the
new RR type. It is a good idea to only discuss one new type in a
document, unless the set of new resource records are closely related
or a protocol extensions requires the use of more than one new record
type. Specifically: each document detailing a new Security related
RR type should include the following information:
@@ -405,13 +411,6 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
DNS Security specifically such as DNS secret key establishment [TKEY]
and security extensions to pre-existing or proposed DNS operations
such as dynamic update [RFC2137]. Documents that describe a new set
of DNS message transactions, or seek to refine a current series of
transaction that make up a DNS operation SHOULD include the following
information:
* The order in which the DNS messages are sent by the operation ini-
tiator and target.
@@ -421,9 +420,16 @@ Rose [Page 7]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
INTERNET-DRAFT DNS Security Document Roadmap January 2001
of DNS message transactions, or seek to refine a current series of
transaction that make up a DNS operation SHOULD include the following
information:
* The order in which the DNS messages are sent by the operation ini-
tiator and target.
* The format of these DNS messages.
* Any required authentication mechanisms for each stage of the
@@ -463,15 +469,8 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
For that reason, the version of the Internet drafts that were refer-
enced in this document are given below:
* SIG0: D. Eastlake. "DNS Request and Transaction Signatures
(SIG(0))" <draft-ietf-dnsext-sig-zero-02.txt>.
* TKEY: D. Eastlake. "Secret Key Establishment for DNS" <draft-
ietf-dnsext-tkey-03.txt>.
* SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". <draft-ietf-
dnsind-sigalgopt-00.txt>
* CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone
Status" <draft-ietf-dnsext-zone-status-01.txt>
* AUTH: B. Wellington. "Domain Name System Security (DNSSEC)
@@ -481,22 +480,33 @@ Rose [Page 8]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
INTERNET-DRAFT DNS Security Document Roadmap January 2001
* CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone
Status" <draft-ietf-dnsext-zone-status-03.txt>
* AUTH: B. Wellington. "Domain Name System Security (DNSSEC)
Signing Authority" <draft-ietf-dnsext-signing-auth-01.txt>
* CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa-
tion in the CAIRN Testbed". <draft-ietf-dnsop-dnsseccairn-00.txt>
* UPDATE: X. Wang, Y. Huang, and D. Rine. "Secure Online Domain
Name System (DNS) Dynamic Update". <draft-whr-dnsext-secure-online-
update-00.txt>
* UPDATE: B. Wellington. "Secure Domain Name System (DNS) Dynamic
Update". <draft-ietf-simple-secure-update-02.txt>
* SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver
message size requirements". <draft-ietf-dnsext-message-size-00.txt>
message size requirements". <draft-ietf-dnsext-message-size-01.txt>
* GSS-TSIG: S. Kwan, P. Garg, J. Gilroy, and L. Esibov. "GSS
Algorithm for TSIG (GSS-TSIG)". <draft-ietf-dnsext-gss-tsig-00.txt>
Algorithm for TSIG (GSS-TSIG)". <draft-ietf-dnsext-gss-tsig-01.txt>
* NO: S. A. Josefsson. "Authenticating Denial of Existence in DNS
with Minimum Disclosure". <draft-jas-dnsext-no-00.txt>
with Minimum Disclosure". <draft-jas-dnsext-no-01.txt>
* OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC".
<draft-ietf-dnsext-dnssec-okbit-01.txt>
* RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)" <draft-ietf-dnsext-rsa-02.txt>
* ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS)
Security Key Rollover" <draft-ietf-dnsopt-rollover-00.txt>.
* ADBIT: B. Wellington. "Redefinition of DNS AD bit" <draft-
ietf-dnsext-ad-is-secure-00.txt>
* OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" <draft-
kosters-dnsext-dnssec-opt-in-00.txt>
7. References
@@ -518,6 +528,24 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
[RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2930] D. Eastlake, "Secret Key Establishment for DNS" RFC 2930,
September 2000.
Rose [Page 9]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
[RFC2931] D. Eastlake "DNS Request and Transaction Signatures
(SIG(0))" RFC 2931, September 2000.
[RFC1591] J. Postal, "Domain Name System Structure and Delegation",
RFC 1591, March 1994.
@@ -531,20 +559,14 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
"Secret Key Transaction Authentication for DNS (TSIG)". RFC 2845,
May 2000.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
ment Levels", RFC-2119, March 1997.
[RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
Update". RFC 3007, November 2000.
Rose [Page 9]
INTERNET-DRAFT DNS Security Document Roadmap August 2000
Requirement Levels", RFC-2119, March 1997.
[RFC3008] B. Wellington, "Domain Name System Security (DNSSEC) Sign-
ing Authority". RFC 3008, November 2000.
@@ -560,8 +582,7 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
Expiration and File Name:
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-00.txt> expires
February 2001
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-01.txt> expires June 2001
@@ -570,6 +591,18 @@ Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
Rose [Page 10]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
@@ -596,41 +629,6 @@ Full Copyright Statement
Rose [Page 10]
INTERNET-DRAFT DNS Security Document Roadmap August 2000

64
doc/draft/draft-ietf-idn-aceid-00.txt → doc/draft/draft-ietf-idn-aceid-01.txt
View File

@@ -1,7 +1,7 @@
Internet Draft Naomasa Maruyama
draft-ietf-idn-aceid-00.txt Yoshiro Yoneya
November 17, 2000 JPNIC
Expires May 17, 2001
draft-ietf-idn-aceid-01.txt Yoshiro Yoneya
Dec 11, 2000 JPNIC
Expires June 11, 2001
Proposal for a determining process of ACE identifier
@@ -75,17 +75,16 @@ identifiers and a method for assigning them.
All strings starting with a combination of two alpha-numericals,
followed by two hyphens, are defined to be ACE prefix identifier
candidates. All strings starting with one hyphen followed by three
alpha-numericals, and strings starting with two hyphens followed by
two alpha-numericals are defined as ACE suffix identifier candidates.
ACE prefix identifier candidates and ACE suffix identifier candidates
are collectively called ACE identifier candidates.
candidates. All strings starting with two hyphens followed by two
alpha-numericals are defined as ACE suffix identifier candidates. ACE
prefix identifier candidates and ACE suffix identifier candidates are
collectively called ACE identifier candidates.
All the domain name registries recognized by ICANN SHOULD
tentatively suspend registration of domain names which have an ACE
prefix identifier candidate at the heads of one of the labels of the
prefix identifier candidate at the head of at least one label of the
domain name and those which have an ACE suffix identifier candidate at
the tail of one of the labels of the name. These domain names are
the tail of at least one label of the name. These domain names are
collectively called "relevant domain names".
This suspension should be continued until March 1, 2001 00:00:00 UTC.
@@ -102,14 +101,14 @@ candidates which are used by relevant domain names.
2.3 Selection of ACE identifiers and permanent blocking of
relevant domain names
The IDN WG MUST summarize the reports and list ACE identifier
candidates that are not reported to be used in registered domain names
by February 17, 2001 00:00:00 UTC, and select ten to twenty ACE prefix
identifier candidates and ten to twenty ACE suffix identifier
candidates for ACE identifiers. Among these twenty to forty ACE
identifiers, one prefix identifier and one suffix identifier will be
used for experiments. Others will be used, one by one as ACE standard
evolves.
The IDN WG or other organ of IETF or ICANN MUST summarize the
reports and list ACE identifier candidates that are not reported to be
used in registered domain names by February 17, 2001 00:00:00 UTC, and
select ten to twenty ACE prefix identifier candidates and ten to
twenty ACE suffix identifier candidates for ACE identifiers. Among
these twenty to forty ACE identifiers, one prefix identifier and one
suffix identifier will be used for experiments. Others will be used,
one by one as ACE standard evolves.
The list of ACE identifiers will be sent to IANA, and will be
maintained by IANA from February 24, 2001 00:00:00 UTC. Domain names
@@ -160,10 +159,24 @@ number, with one of the ACE identifiers.
5. Security considerations
None in particular.
None in particular.
6. References
6. Changes from the previous version
We excluded suffixes of one hyphen followed by three alpha-
numericals from the candidates. This is because we found that, as of
Nov. 29, 2000, there were 23,921 domain names registered in the .JP
space relevant to these suffixes. This was more than 10% of 227,852
total registrations in the JPNIC database at the moment, and hence we
felt these suffixes are not good candidates.
In addition to this and some minor linguistic corrections, we
changed "The IDN WG" in section 2.3 to "The IDN WG or other organ of
IETF or ICANN".
7. References
[IDNREQ] Z Wenzel, J Seng, "Requirements of Internationalized Domain
Names", draft-ietf-idn-requirements-03.txt, Jun 2000.
@@ -181,12 +194,15 @@ None in particular.
names protocols", draft-ietf-idn-version-00.txt, Nov 2000.
7. Acknowledgements
8. Acknowledgements
JPNIC IDN-TF members,
Dave Crocker.
We would like to express our hearty thanks to members of JPNIC IDN
Task Force for valuable discussions about this issue. We also would
like to express our appreciation to Mr. Dave Crocker for checking and
correcting the preliminary version of this draft.
8. Author's Address
9. Author's Address
Naomasa Maruyama
Japan Network Information Center

182
doc/draft/draft-klensin-1591-reflections-01.txt → doc/draft/draft-klensin-1591-reflections-02.txt
View File

@@ -1,10 +1,9 @@
INTERNET-DRAFT John C. Klensin
Expires May 2001
November 10, 2000
December 13, 2000
Expires June 2000
Reflections on the DNS, RFC 1591, and Categories of Domains
draft-klensin-1591-reflections-01.txt
draft-klensin-1591-reflections-02.txt
Status of this Memo
@@ -47,22 +46,25 @@ bodies to update it or adjust its provisions, sometimes under
pressures that have arguably produced policies that are less well
thought out than the original. Some of those efforts have begun from
misconceptions about the provisions of 1591 or the motivation for
those provisions. This memo includes some thoughts about how 1591
might be interpreted and adjusted by the IANA and ICANN to better
reflect today's world while retaining characteristics and policies
that have proven to be effective in supporting Internet growth and
stability. An earlier variation of this memo was submitted to ICANN
as a comment on its evolving TLD policies.
those provisions. The current directions of ICANN and other groups
who now determine DNS policy directions appear to be drifting away
from policies and philosophy of 1591. This document is being
published primarily for historical context and comparative purposes,
essentially to document some thoughts about how 1591 might have been
interpreted and adjusted by the IANA and ICANN to better reflect
today's world while retaining characteristics and policies that have
proven to be effective in supporting Internet growth and stability.
An earlier variation of this memo was submitted to ICANN as a comment
on its evolving TLD policies.
1. Introduction
RFC1591 has been heavily discussed and referenced in recent months,
especially in discussions within ICANN and its predecessors about the
creation, delegation, and management of top-level domains. In
particular, the ICANN Domain Name Supporting Organization (DNSO), and
especially its ccTLD constituency, have been the home of many
RFC1591 has been heavily discussed and referenced in the last year or
two, especially in discussions within ICANN and its predecessors
about the creation, delegation, and management of top-level domains.
In particular, the ICANN Domain Name Supporting Organization (DNSO),
and especially its ccTLD constituency, have been the home of many
discussions in which 1591 and interpretations of it have been cited
in support of a variety of sometimes-contradictory positions. During
that period, other discussions have gone on to try to reconstruct the
@@ -84,7 +86,7 @@ within the broad contexts of "public service on behalf of the
Internet community" and "trustee... for the global Internet
community"-- was considered a design feature and a safeguard against
a variety of potential abuses. Obviously the world has changed in
many ways in the five or six years since 1591 was written. In
many ways in the six or seven years since 1591 was written. In
particular, the Internet has become more heavily used and, because
the design of the world wide web has put domain names in front of
users, top-level domain names and registrations in them have been
@@ -93,32 +95,33 @@ dramatically during that time, but the ratio between registered
domain names and physical hosts has increased very significantly.
The issues 1591 attempted to address when it was written and those we
face today have not changed significantly in principle. But we should
take a step back to refine it into a model that can function
effectively today. Therefore, it may be useful to try to reconstruct
1591's principles and think about their applicability today as a
model that can continue to be applied: not because it is historically
significant, but because many of its elements have proven to work
reasonably well, even in difficult situations. In particular, for
many domains (some in 1591's "generic" list and others in its
"country code" category) the notion of "public service" --expected
then to imply being carried out at no or minimal cost to the users,
not merely on a non-profit basis-- has yielded to profitability
calculations. And, in most of the rest, considerations of at least
calculating and recovering costs have crept in. While many of us
feel some nostalgia for the old system, it is clear that its days are
waning if not gone: perhaps the public service notions as understood
when 1591 was written just don't scale to rapid internet growth and
very large numbers of registrations.
face today have not changed significantly in principle. But one
alternative to present trends would be to take a step back to refine
it into a model that can function effectively today. Therefore, it
may be useful to try to reconstruct 1591's principles and think about
their applicability today as a model that could continue to be
applied: not because it is historically significant, but because many
of its elements have proven to work reasonably well, even in
difficult situations. In particular, for many domains (some in
1591's "generic" list and others in its "country code" category) the
notion of "public service" --expected then to imply being carried out
at no or minimal cost to the users, not merely on a non-profit
basis-- has yielded to profitability calculations. And, in most of
the rest, considerations of at least calculating and recovering costs
have crept in. While many of us feel some nostalgia for the old
system, it is clear that its days are waning if not gone: perhaps the
public service notions as understood when 1591 was written just don't
scale to rapid internet growth and very large numbers of
registrations.
In particular, some ccTLDs have advertised for registrations outside
the designated countries (or other entities), while others have made
clear decisions to allow registrations by non-nationals (e.g., the UK
or Australia). These decisions and others have produced protests
from many sides, suggesting, in turn, that a recategorization is in
order. For example, we have heard concerns by governments and
managers of traditional, "public service", in-country, ccTLDs about
excessive ICANN interference and fears of being forced to conform to
clear decisions to allow registrations by non-nationals. These
decisions and others have produced protests from many sides,
suggesting, in turn, that a recategorization is in order. For
example, we have heard concerns by governments and managers of
traditional, "public service", in-country, ccTLDs about excessive
ICANN interference and fears of being forced to conform to
internationally-set policies for dispute resolution when their
domestic ones are considered more appropriate. We have also heard
concerns from registrars and operators of externally-marketed ccTLDs
@@ -146,9 +149,8 @@ ccTLDs but among:
Government TLDs MIL and GOV. There have been proposals from
time to time for other international TLDs of this variety, e.g.,
for medical entities such as physicians and hospitals and for
museums. Some of these proposals are in front of ICANN as this
document is being written; ICANN describes them as "sponsored"
TLDs.
museums. ICANN has recently approved several TLDs of this type
and describes them as "sponsored" TLDs.
(iii) Country domains, operated according to the original
underlying assumptions of 1591, i.e., registrants are largely
@@ -171,15 +173,16 @@ registered 3166-1 two letter codes should be used as two-letter TLDs.
2. Implications of the Categories
If we adopt this type of three-way categorization and can make it
work, I believe it presents several opportunities for ICANN and the
community more generally to reduce controversies and move forward. Of
course, there will be cases where the categorization of a particular
domain and its operating style will not be completely clear-cut (see
section 3, below). But having ICANN work out procedures for dealing
with those (probably few) situations appears preferable to strategies
that would tend to propel ICANN into areas that are beyond its
competence or that might require significant expansion of its mandate.
If we had adopted this type of three-way categorization and could
make it work, I believe it would have presented several opportunities
for ICANN and the community more generally to reduce controversies
and move forward. Of course, there will be cases where the
categorization of a particular domain and its operating style will
not be completely clear-cut (see section 3, below). But having ICANN
work out procedures for dealing with those (probably few) situations
appears preferable to strategies that would tend to propel ICANN into
areas that are beyond its competence or that might require
significant expansion of its mandate.
First, the internally-operated ccTLDs (category iii above) should not
be required to have much interaction with ICANN or vice versa. Once
@@ -250,7 +253,7 @@ Internet interoperability and stability.
ICANN's avoiding such involvement strengthens it: the desirability of
avoiding collisions with national sovereignty, determinations about
government legitimacy, and the authority of someone proportedly
government legitimacy, and the authority of someone purportedly
writing on behalf of a government, is as important today as it was
when 1591 was written. The alternatives take us quickly from
"administration" into "internet governance" or, in the case of
@@ -293,38 +296,39 @@ This, obviously, is also the argument against use of the "reserved"
list, at least without explicit agreement with 3166/MA: since IANA
(or ICANN) can ask that a name be placed on that list, there is no
rule of an absolute determination by an external organization.
Proported countries can come to ICANN, insist on having delegations
Purported countries can come to ICANN, insist on having delegations
made and persuade ICANN to ask that the names be reserved. Then,
since the reserved name would exist, insist that the domain be
delegated. Worse, someone could use another organization to request
reservation of the name by 3166/MA; once it was reserved, ICANN might
be hard-pressed not to do the delegation. Of course, ICANN could
(and probably would be forced to) adopt additional criteria other
than appearance on the "reserved list" in order to delegate such
domains. But those criteria would almost certainly be nearly
equivalent to determining which applicants were legitimate and stable
enough to be considered a country, the exact decision process that
1591 strove to avoid.
since the reserved name would exist, they could insist that the
domain be delegated. Worse, someone could use another organization
to request reservation of the name by 3166/MA; once it was reserved,
ICANN might be hard-pressed not to do the delegation. Of course,
ICANN could (and probably would be forced to) adopt additional
criteria other than appearance on the "reserved list" in order to
delegate such domains. But those criteria would almost certainly be
nearly equivalent to determining which applicants were legitimate and
stable enough to be considered a country, the exact decision process
that 1591 strove to avoid.
The other two considerations were more subtle and not always
successful: from time to time, both before and after the formal
policy shifted toward "governments could have their way", IANA
received letters from people proporting to be competent government
received letters from people purporting to be competent government
authorities asking for changes. Some of them turned out later to not
have that authority or those qualifications. The assumption of 1591
itself was that, if the "administrative contact in country" rule was
strictly observed, as was the rule that delegation changes requested
by the administrative contact would be honored, then, if a government
_really_ wanted to assert itself, it could pressure the
have that authority or appropriate qualifications. The assumption of
1591 itself was that, if the "administrative contact in country" rule
was strictly observed, as was the rule that delegation changes
requested by the administrative contact would be honored, then, if a
government _really_ wanted to assert itself, it could pressure the
administrative contact into requesting the changes it wanted, using
whatever would pass for due process in that country. And the ability
to apply that process and pressure would effectively determine who
was the government and who wasn't, and would do so far more
effectively than any IANA evaluation of, e.g., whether the letterhead
on a request looked authentic (and far more safely for ICANN than
asking the opinion of any particular other government).
asking the opinion of any particular other government or selection of
governments).
Specific language in 1591 permitted IANA to adopt a "work it our
Specific language in 1591 permitted IANA to adopt a "work it out
yourselves; if we have to decide, we will strive for a solution that
is not satisfactory to any party" stance. That approach was used
successfully, along with large doses of education, on many occasions
@@ -342,7 +346,8 @@ make a change, the best mechanism for doing so is not to involve
ICANN in a potential determination of legitimacy (or even to have the
GAC try to formally make that decision for individual countries) but
for the relevant government to use its own procedures to persuade the
administrative contact to request the change.
administrative contact to request the change and for IANA to promptly
and efficiently carry out requests made by administrative contacts.
6. Implications for the current DNSO structure.
@@ -351,15 +356,15 @@ The arguments by some of the ccTLD administrators that they are
different from the rest of the ICANN and DNSO structures are (in this
model) correct: they are different. The ccTLDs that are operating as
generic TLDs should be separated from the ccTLD constituency and
joined to the gTLD constituency (which could use a few more members).
The country ccTLDs should be separated from ICANN's immediate
Supporting Organization structure, and operate in a parallel and
advisory capacity to ICANN, similar to the arrangements used with the
GAC. The DNSO and country TLDs should not be required to interact
with each other except on a mutually voluntary basis and, if ICANN
needs interaction or advice from some of all of those TLDs, it would
be more appropriate to get it in the form of an advisory body like
the GAC rather than as DNSO constituency.
joined to the gTLD constituency. The country ccTLDs should be
separated from ICANN's immediate Supporting Organization structure,
and operate in a parallel and advisory capacity to ICANN, similar to
the arrangements used with the GAC. The DNSO and country TLDs should
not be required to interact with each other except on a mutually
voluntary basis and, if ICANN needs interaction or advice from some
of all of those TLDs, it would be more appropriate to get it in the
form of an advisory body like the GAC rather than as DNSO
constituency.
7. References
@@ -372,12 +377,13 @@ the GAC rather than as DNSO constituency.
These reflections have been prepared in my individual capacity and do
not necessarily reflect the views of my past or present employers.
Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel
and several anonymous reviewers, made suggestions about earlier
versions of this document. Those comments contributed significantly
to whatever clarity the document has, but the author bears
responsibility for the selection of comments which were ultimately
incorporated and the way in which the conclusions were presented.
Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
suggestions or offered editorial comments about earlier versions of
this document. Those comments contributed significantly to whatever
clarity the document has, but the author bears responsibility for the
selection of comments which were ultimately incorporated and the way
in which the conclusions were presented.
9. Security Considerations