diff --git a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-01.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt rename to doc/draft/draft-ietf-dnsext-dnssec-roadmap-01.txt index 22ec053a35..ab71667e7b 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-01.txt @@ -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 ------------------------------ - + 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))" . - * TKEY: D. Eastlake. "Secret Key Establishment for DNS" . * SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". - * CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone - Status" - * 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" + * AUTH: B. Wellington. "Domain Name System Security (DNSSEC) Signing Authority" * CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa- tion in the CAIRN Testbed". - * UPDATE: X. Wang, Y. Huang, and D. Rine. "Secure Online Domain - Name System (DNS) Dynamic Update". + * UPDATE: B. Wellington. "Secure Domain Name System (DNS) Dynamic + Update". * SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver - message size requirements". + message size requirements". * GSS-TSIG: S. Kwan, P. Garg, J. Gilroy, and L. Esibov. "GSS - Algorithm for TSIG (GSS-TSIG)". + Algorithm for TSIG (GSS-TSIG)". * NO: S. A. Josefsson. "Authenticating Denial of Existence in DNS - with Minimum Disclosure". - + with Minimum Disclosure". + * OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC". + + * RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)" + * ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS) + Security Key Rollover" . + * ADBIT: B. Wellington. "Redefinition of DNS AD bit" + * OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" 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 expires -February 2001 + This draft, titled 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-idn-aceid-00.txt b/doc/draft/draft-ietf-idn-aceid-01.txt similarity index 77% rename from doc/draft/draft-ietf-idn-aceid-00.txt rename to doc/draft/draft-ietf-idn-aceid-01.txt index 5aa3664772..deaf3cb69c 100644 --- a/doc/draft/draft-ietf-idn-aceid-00.txt +++ b/doc/draft/draft-ietf-idn-aceid-01.txt @@ -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 diff --git a/doc/draft/draft-klensin-1591-reflections-01.txt b/doc/draft/draft-klensin-1591-reflections-02.txt similarity index 72% rename from doc/draft/draft-klensin-1591-reflections-01.txt rename to doc/draft/draft-klensin-1591-reflections-02.txt index 85c98b3055..678d12904d 100644 --- a/doc/draft/draft-klensin-1591-reflections-01.txt +++ b/doc/draft/draft-klensin-1591-reflections-02.txt @@ -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