mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-09-01 06:55:30 +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 DNEXT Working Group S. Rose
Internet Draft NIST Internet Draft NIST
Expires: February 2001 August 2000 Expires: June 2001 January 2001
Category: Informational Category: Informational
@@ -14,7 +14,7 @@ Category: Informational
DNS Security Document Roadmap DNS Security Document Roadmap
------------------------------ ------------------------------
<draft-ietf-dnsext-dnssec-roadmap-00.txt> <draft-ietf-dnsext-dnssec-roadmap-01.txt>
Status of this Document 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 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 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 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 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 | | Security | <------->| protocol |<-------->| Security |
| RRs | | | | Uses | | RRs | | | | Uses |
| [RFC2538, | | [RFC2535, | | | | [RFC2538, | | [RFC2535, | | |
| SIG0 NO] | | CLARIFY, | +-------------+ | RFC2931, | | RFC3007, | +-------------+
+------------+ | AUTH, | | NO] | | RFC3008, |
+------------+ | CLARIFY, |
| SIZE ] | | SIZE ] |
| OKBIT, |
| ADBIT, |
| OPTIN ] |
+-----------+ +-----------+
| |
| |
@@ -219,19 +222,15 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
| DS | | | | Implementation | | DS | | | | Implementation |
| Algorithm | | Transactions | * Notes * | Algorithm | | Transactions | * Notes *
| Impl. | | | | | | Impl. | | | | |
| [RFC2536, | | [RFC2845, | * [CAIRN] * | [RFC2536, | | [RFC2845, | * [CAIRN, *
| RFC2537 | | TKEY] | | | | RFC2537 | | RFC2930] | | ROLLOVER ] |
| RFC2539 | | | * * | RFC2539 | | | * *
| GSS-TSIG] | | | +-*-*-*-*-*-*-*-*-+ | GSS-TSIG, | | | +-*-*-*-*-*-*-*-*-+
+------------+ +---------------+ | RSA-SHA] | +---------------+
+------------+
Figure 1 DNSSEC Document Roadmap 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- groups include the implementation documents of various digital signa-
ture algorithms with DNSSEC, and documents further refining the tran- ture algorithms with DNSSEC, and documents further refining the tran-
saction of messages. It is expected that RFC 2535 will be obseleted 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 lines of RFC/Internet Draft author guidelines). Also, the portions
of the specification to be modified SHOULD be synopsized in the new of the specification to be modified SHOULD be synopsized in the new
document for the benefit of the reader. The "DNSSEC protocol" set document for the benefit of the reader. The "DNSSEC protocol" set
includes the documents [RFC2535], [CLARIFY], [AUTH], [SIZE] and their includes the documents [RFC2535], [RFC3007], [RFC3008], [CLARIFY],
derivative documents. [SIZE], [OKBIT], [ADBIT] and their derivative documents.
The "New Security RRs" set refers to the group of documents that seek 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 to add additional Resource Record to the set of base DNS Record
types. These new records can be related to securing the DNS protocol types. These new records can be related to securing the DNS protocol
[RFC2535] [SIG0] [NO] or using DNS security for other purposes such [RFC2535], [RFC2931], [NO] or using DNS security for other purposes
as storing certificates [RFC2538]. such as storing certificates [RFC2538].
The "DS Algorithm Impl" document set refers to the group of documents The "DS Algorithm Impl" document set refers to the group of documents
that describe how a specific digital signature algorithm is imple- that describe how a specific digital signature algorithm is imple-
mented to fit the DNSSEC Resource Record format. Each one of these mented to fit the DNSSEC Resource Record format. Each one of these
documents deals with one specific digital signature algorithm. Exam- documents deals with one specific digital signature algorithm. Exam-
ples of this set include [RFC2536] [RFC2537] [RFC2539] and [GSS- ples of this set include [RFC2536], [RFC2537], [RFC2539], [RSA-SHA]
TSIG]. and [GSS-TSIG].
The "Transactions" document set refers to the group of documents that The "Transactions" document set refers to the group of documents that
deal with the message transaction sequence of security related DNS 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 update [RFC2137] [UPDATE] and transaction signatures [RFC2845] are
described in this document category. Additional message transaction described in this document category. Additional message transaction
schemes to support DNSSEC operation would also fall under this group, 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 The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security 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 Lastly, there is a set of documents that should be classified as
"Implementation Notes". Because the DNS security extensions are "Implementation Notes". Because the DNS security extensions are
still in the developmental stage, there is an audience for documents 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 that detail the transition and implementation of the security exten-
on the CAIRN DNSSEC testbed [CAIRN]. This document was submitted sions. These have more to do with the practical side of DNS opera-
through the DNSOP working group, however the main concern of this tions, but can also point to places in the protocol specifications
document in the implementation and limitations of the DNS security that need improvement. Documents in this set may be offspring of
extensions, hence its interest to the DNS security community. both the DNSEXT and/or DNSOP working groups. Currently, there are
Authors of documents that deal with the implementation and opera- two Internet Drafts that falls under this category: The report on
tional side of the DNSSEC specifications would be advised/encouraged the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
to submit their documents to the DNSEXT working group as well. [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 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. 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] 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 type. Specifically: each document detailing a new Security related
RR type should include the following information: 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] DNS Security specifically such as DNS secret key establishment [TKEY]
and security extensions to pre-existing or proposed DNS operations and security extensions to pre-existing or proposed DNS operations
such as dynamic update [RFC2137]. Documents that describe a new set 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. * The format of these DNS messages.
* Any required authentication mechanisms for each stage of the * 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- For that reason, the version of the Internet drafts that were refer-
enced in this document are given below: 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- * SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". <draft-ietf-
dnsind-sigalgopt-00.txt> 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> Signing Authority" <draft-ietf-dnsext-signing-auth-01.txt>
* CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa- * CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa-
tion in the CAIRN Testbed". <draft-ietf-dnsop-dnsseccairn-00.txt> tion in the CAIRN Testbed". <draft-ietf-dnsop-dnsseccairn-00.txt>
* UPDATE: X. Wang, Y. Huang, and D. Rine. "Secure Online Domain * UPDATE: B. Wellington. "Secure Domain Name System (DNS) Dynamic
Name System (DNS) Dynamic Update". <draft-whr-dnsext-secure-online- Update". <draft-ietf-simple-secure-update-02.txt>
update-00.txt>
* SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver * 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 * 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 * 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 7. References
@@ -518,6 +528,24 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
[RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the [RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999. 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", [RFC1591] J. Postal, "Domain Name System Structure and Delegation",
RFC 1591, March 1994. 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, "Secret Key Transaction Authentication for DNS (TSIG)". RFC 2845,
May 2000. 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.
[RFC3008] B. Wellington, "Domain Name System Security (DNSSEC) Sign-
Rose [Page 9] ing Authority". RFC 3008, November 2000.
INTERNET-DRAFT DNS Security Document Roadmap August 2000
Requirement Levels", RFC-2119, March 1997.
@@ -560,8 +582,7 @@ INTERNET-DRAFT DNS Security Document Roadmap August 2000
Expiration and File Name: Expiration and File Name:
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-00.txt> expires This draft, titled <draft-ietf-dnsext-dnssec-roadmap-01.txt> expires June 2001
February 2001
@@ -570,6 +591,18 @@ Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to 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 others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any 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 Internet Draft Naomasa Maruyama
draft-ietf-idn-aceid-00.txt Yoshiro Yoneya draft-ietf-idn-aceid-01.txt Yoshiro Yoneya
November 17, 2000 JPNIC Dec 11, 2000 JPNIC
Expires May 17, 2001 Expires June 11, 2001
Proposal for a determining process of ACE identifier 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, All strings starting with a combination of two alpha-numericals,
followed by two hyphens, are defined to be ACE prefix identifier followed by two hyphens, are defined to be ACE prefix identifier
candidates. All strings starting with one hyphen followed by three candidates. All strings starting with two hyphens followed by two
alpha-numericals, and strings starting with two hyphens followed by alpha-numericals are defined as ACE suffix identifier candidates. ACE
two alpha-numericals are defined as ACE suffix identifier candidates. prefix identifier candidates and ACE suffix identifier candidates are
ACE prefix identifier candidates and ACE suffix identifier candidates collectively called ACE identifier candidates.
are collectively called ACE identifier candidates.
All the domain name registries recognized by ICANN SHOULD All the domain name registries recognized by ICANN SHOULD
tentatively suspend registration of domain names which have an ACE 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 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". collectively called "relevant domain names".
This suspension should be continued until March 1, 2001 00:00:00 UTC. 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 2.3 Selection of ACE identifiers and permanent blocking of
relevant domain names relevant domain names
The IDN WG MUST summarize the reports and list ACE identifier The IDN WG or other organ of IETF or ICANN MUST summarize the
candidates that are not reported to be used in registered domain names reports and list ACE identifier candidates that are not reported to be
by February 17, 2001 00:00:00 UTC, and select ten to twenty ACE prefix used in registered domain names by February 17, 2001 00:00:00 UTC, and
identifier candidates and ten to twenty ACE suffix identifier select ten to twenty ACE prefix identifier candidates and ten to
candidates for ACE identifiers. Among these twenty to forty ACE twenty ACE suffix identifier candidates for ACE identifiers. Among
identifiers, one prefix identifier and one suffix identifier will be these twenty to forty ACE identifiers, one prefix identifier and one
used for experiments. Others will be used, one by one as ACE standard suffix identifier will be used for experiments. Others will be used,
evolves. one by one as ACE standard evolves.
The list of ACE identifiers will be sent to IANA, and will be 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 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 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 [IDNREQ] Z Wenzel, J Seng, "Requirements of Internationalized Domain
Names", draft-ietf-idn-requirements-03.txt, Jun 2000. 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. names protocols", draft-ietf-idn-version-00.txt, Nov 2000.
7. Acknowledgements 8. Acknowledgements
JPNIC IDN-TF members, We would like to express our hearty thanks to members of JPNIC IDN
Dave Crocker. 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 Naomasa Maruyama
Japan Network Information Center 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 INTERNET-DRAFT John C. Klensin
Expires May 2001 December 13, 2000
November 10, 2000 Expires June 2000
Reflections on the DNS, RFC 1591, and Categories of Domains Reflections on the DNS, RFC 1591, and Categories of Domains
draft-klensin-1591-reflections-02.txt
draft-klensin-1591-reflections-01.txt
Status of this Memo 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 pressures that have arguably produced policies that are less well
thought out than the original. Some of those efforts have begun from thought out than the original. Some of those efforts have begun from
misconceptions about the provisions of 1591 or the motivation for misconceptions about the provisions of 1591 or the motivation for
those provisions. This memo includes some thoughts about how 1591 those provisions. The current directions of ICANN and other groups
might be interpreted and adjusted by the IANA and ICANN to better who now determine DNS policy directions appear to be drifting away
reflect today's world while retaining characteristics and policies from policies and philosophy of 1591. This document is being
that have proven to be effective in supporting Internet growth and published primarily for historical context and comparative purposes,
stability. An earlier variation of this memo was submitted to ICANN essentially to document some thoughts about how 1591 might have been
as a comment on its evolving TLD policies. 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 1. Introduction
RFC1591 has been heavily discussed and referenced in recent months, RFC1591 has been heavily discussed and referenced in the last year or
especially in discussions within ICANN and its predecessors about the two, especially in discussions within ICANN and its predecessors
creation, delegation, and management of top-level domains. In about the creation, delegation, and management of top-level domains.
particular, the ICANN Domain Name Supporting Organization (DNSO), and In particular, the ICANN Domain Name Supporting Organization (DNSO),
especially its ccTLD constituency, have been the home of many and especially its ccTLD constituency, have been the home of many
discussions in which 1591 and interpretations of it have been cited discussions in which 1591 and interpretations of it have been cited
in support of a variety of sometimes-contradictory positions. During in support of a variety of sometimes-contradictory positions. During
that period, other discussions have gone on to try to reconstruct the 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 Internet community" and "trustee... for the global Internet
community"-- was considered a design feature and a safeguard against community"-- was considered a design feature and a safeguard against
a variety of potential abuses. Obviously the world has changed in 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 particular, the Internet has become more heavily used and, because
the design of the world wide web has put domain names in front of 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 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. domain names and physical hosts has increased very significantly.
The issues 1591 attempted to address when it was written and those we The issues 1591 attempted to address when it was written and those we
face today have not changed significantly in principle. But we should face today have not changed significantly in principle. But one
take a step back to refine it into a model that can function alternative to present trends would be to take a step back to refine
effectively today. Therefore, it may be useful to try to reconstruct it into a model that can function effectively today. Therefore, it
1591's principles and think about their applicability today as a may be useful to try to reconstruct 1591's principles and think about
model that can continue to be applied: not because it is historically their applicability today as a model that could continue to be
significant, but because many of its elements have proven to work applied: not because it is historically significant, but because many
reasonably well, even in difficult situations. In particular, for of its elements have proven to work reasonably well, even in
many domains (some in 1591's "generic" list and others in its difficult situations. In particular, for many domains (some in
"country code" category) the notion of "public service" --expected 1591's "generic" list and others in its "country code" category) the
then to imply being carried out at no or minimal cost to the users, notion of "public service" --expected then to imply being carried out
not merely on a non-profit basis-- has yielded to profitability at no or minimal cost to the users, not merely on a non-profit
calculations. And, in most of the rest, considerations of at least basis-- has yielded to profitability calculations. And, in most of
calculating and recovering costs have crept in. While many of us the rest, considerations of at least calculating and recovering costs
feel some nostalgia for the old system, it is clear that its days are have crept in. While many of us feel some nostalgia for the old
waning if not gone: perhaps the public service notions as understood system, it is clear that its days are waning if not gone: perhaps the
when 1591 was written just don't scale to rapid internet growth and public service notions as understood when 1591 was written just don't
very large numbers of registrations. scale to rapid internet growth and very large numbers of
registrations.
In particular, some ccTLDs have advertised for registrations outside In particular, some ccTLDs have advertised for registrations outside
the designated countries (or other entities), while others have made the designated countries (or other entities), while others have made
clear decisions to allow registrations by non-nationals (e.g., the UK clear decisions to allow registrations by non-nationals. These
or Australia). These decisions and others have produced protests decisions and others have produced protests from many sides,
from many sides, suggesting, in turn, that a recategorization is in suggesting, in turn, that a recategorization is in order. For
order. For example, we have heard concerns by governments and example, we have heard concerns by governments and managers of
managers of traditional, "public service", in-country, ccTLDs about traditional, "public service", in-country, ccTLDs about excessive
excessive ICANN interference and fears of being forced to conform to ICANN interference and fears of being forced to conform to
internationally-set policies for dispute resolution when their internationally-set policies for dispute resolution when their
domestic ones are considered more appropriate. We have also heard domestic ones are considered more appropriate. We have also heard
concerns from registrars and operators of externally-marketed ccTLDs 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 Government TLDs MIL and GOV. There have been proposals from
time to time for other international TLDs of this variety, e.g., time to time for other international TLDs of this variety, e.g.,
for medical entities such as physicians and hospitals and for for medical entities such as physicians and hospitals and for
museums. Some of these proposals are in front of ICANN as this museums. ICANN has recently approved several TLDs of this type
document is being written; ICANN describes them as "sponsored" and describes them as "sponsored" TLDs.
TLDs.
(iii) Country domains, operated according to the original (iii) Country domains, operated according to the original
underlying assumptions of 1591, i.e., registrants are largely 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 2. Implications of the Categories
If we adopt this type of three-way categorization and can make it If we had adopted this type of three-way categorization and could
work, I believe it presents several opportunities for ICANN and the make it work, I believe it would have presented several opportunities
community more generally to reduce controversies and move forward. Of for ICANN and the community more generally to reduce controversies
course, there will be cases where the categorization of a particular and move forward. Of course, there will be cases where the
domain and its operating style will not be completely clear-cut (see categorization of a particular domain and its operating style will
section 3, below). But having ICANN work out procedures for dealing not be completely clear-cut (see section 3, below). But having ICANN
with those (probably few) situations appears preferable to strategies work out procedures for dealing with those (probably few) situations
that would tend to propel ICANN into areas that are beyond its appears preferable to strategies that would tend to propel ICANN into
competence or that might require significant expansion of its mandate. 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 First, the internally-operated ccTLDs (category iii above) should not
be required to have much interaction with ICANN or vice versa. Once 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 ICANN's avoiding such involvement strengthens it: the desirability of
avoiding collisions with national sovereignty, determinations about 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 writing on behalf of a government, is as important today as it was
when 1591 was written. The alternatives take us quickly from when 1591 was written. The alternatives take us quickly from
"administration" into "internet governance" or, in the case of "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 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 (or ICANN) can ask that a name be placed on that list, there is no
rule of an absolute determination by an external organization. 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, made and persuade ICANN to ask that the names be reserved. Then,
since the reserved name would exist, insist that the domain be since the reserved name would exist, they could insist that the
delegated. Worse, someone could use another organization to request domain be delegated. Worse, someone could use another organization
reservation of the name by 3166/MA; once it was reserved, ICANN might to request reservation of the name by 3166/MA; once it was reserved,
be hard-pressed not to do the delegation. Of course, ICANN could ICANN might be hard-pressed not to do the delegation. Of course,
(and probably would be forced to) adopt additional criteria other ICANN could (and probably would be forced to) adopt additional
than appearance on the "reserved list" in order to delegate such criteria other than appearance on the "reserved list" in order to
domains. But those criteria would almost certainly be nearly delegate such domains. But those criteria would almost certainly be
equivalent to determining which applicants were legitimate and stable nearly equivalent to determining which applicants were legitimate and
enough to be considered a country, the exact decision process that stable enough to be considered a country, the exact decision process
1591 strove to avoid. that 1591 strove to avoid.
The other two considerations were more subtle and not always The other two considerations were more subtle and not always
successful: from time to time, both before and after the formal successful: from time to time, both before and after the formal
policy shifted toward "governments could have their way", IANA 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 authorities asking for changes. Some of them turned out later to not
have that authority or those qualifications. The assumption of 1591 have that authority or appropriate qualifications. The assumption of
itself was that, if the "administrative contact in country" rule was 1591 itself was that, if the "administrative contact in country" rule
strictly observed, as was the rule that delegation changes requested was strictly observed, as was the rule that delegation changes
by the administrative contact would be honored, then, if a government requested by the administrative contact would be honored, then, if a
_really_ wanted to assert itself, it could pressure the government _really_ wanted to assert itself, it could pressure the
administrative contact into requesting the changes it wanted, using administrative contact into requesting the changes it wanted, using
whatever would pass for due process in that country. And the ability whatever would pass for due process in that country. And the ability
to apply that process and pressure would effectively determine who to apply that process and pressure would effectively determine who
was the government and who wasn't, and would do so far more was the government and who wasn't, and would do so far more
effectively than any IANA evaluation of, e.g., whether the letterhead effectively than any IANA evaluation of, e.g., whether the letterhead
on a request looked authentic (and far more safely for ICANN than 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 yourselves; if we have to decide, we will strive for a solution that
is not satisfactory to any party" stance. That approach was used is not satisfactory to any party" stance. That approach was used
successfully, along with large doses of education, on many occasions 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 ICANN in a potential determination of legitimacy (or even to have the
GAC try to formally make that decision for individual countries) but GAC try to formally make that decision for individual countries) but
for the relevant government to use its own procedures to persuade the 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. 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 different from the rest of the ICANN and DNSO structures are (in this
model) correct: they are different. The ccTLDs that are operating as model) correct: they are different. The ccTLDs that are operating as
generic TLDs should be separated from the ccTLD constituency and generic TLDs should be separated from the ccTLD constituency and
joined to the gTLD constituency (which could use a few more members). joined to the gTLD constituency. The country ccTLDs should be
The country ccTLDs should be separated from ICANN's immediate separated from ICANN's immediate Supporting Organization structure,
Supporting Organization structure, and operate in a parallel and and operate in a parallel and advisory capacity to ICANN, similar to
advisory capacity to ICANN, similar to the arrangements used with the the arrangements used with the GAC. The DNSO and country TLDs should
GAC. The DNSO and country TLDs should not be required to interact not be required to interact with each other except on a mutually
with each other except on a mutually voluntary basis and, if ICANN voluntary basis and, if ICANN needs interaction or advice from some
needs interaction or advice from some of all of those TLDs, it would of all of those TLDs, it would be more appropriate to get it in the
be more appropriate to get it in the form of an advisory body like form of an advisory body like the GAC rather than as DNSO
the GAC rather than as DNSO constituency. constituency.
7. References 7. References
@@ -372,12 +377,13 @@ the GAC rather than as DNSO constituency.
These reflections have been prepared in my individual capacity and do These reflections have been prepared in my individual capacity and do
not necessarily reflect the views of my past or present employers. not necessarily reflect the views of my past or present employers.
Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
and several anonymous reviewers, made suggestions about earlier Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
versions of this document. Those comments contributed significantly suggestions or offered editorial comments about earlier versions of
to whatever clarity the document has, but the author bears this document. Those comments contributed significantly to whatever
responsibility for the selection of comments which were ultimately clarity the document has, but the author bears responsibility for the
incorporated and the way in which the conclusions were presented. selection of comments which were ultimately incorporated and the way
in which the conclusions were presented.
9. Security Considerations 9. Security Considerations