draft-klensin-1591-reflections-02.txt

bind-3.2.

in which the domain participates.

By contrast, ccTLDs operated as generic domains ought to be treated
as generic domains.  ICANN dispute resolution and name management
policies and any special rules developed to protect the Internet
public in multiple registrar or registry situations should reasonably
apply.

3.  Telling TLD types apart

If appropriate policies are adopted, ccTLDs operated as generic
domains (category (i) above) and those operated as country domains
(category (iii) above) ought to be able to be self-identified.  There
are several criteria that could be applied to make this
determination. For example, either a domain is aggressively seeking
outside registrations or it is not and either the vast majority of
registrants in a domain are in-country or they are not. One could
also think of this as the issue of having some tangible level of
presence in the jurisdiction - e.g., is the administrative contact
subject, in practical terms, to the in-country laws, or are the
registration rules such that it is reasonably likely that a court in
the jurisdiction of the country associated with the domain can
exercise jurisdiction and enforce a judgment against the registrant.

One (fairly non-intrusive) rule ICANN might well impose on all
top-level domains is that they identify and publish the policies they
intend to use.  E.g., registrants in a domain that will use the laws
of one particular country to resolve disputes should have a
reasonable opportunity to understand those policies prior to
registration and to make other arrangements (e.g., to register
elsewhere) if that mechanism for dispute resolution is not
acceptable.  Giving IANA (as the root registrar) incorrect
information about the purpose and use of a domain should be subject
to challenge, and should be grounds for reviewing the appropriateness
of the domain delegation, just as not acting consistently and
equitably provides such grounds under the original provisions of RFC
1591.

In order to ensure the availability of accurate and up-to-date
registration information the criteria must be consistent, and
consistent with more traditional gTLDs, for all nominally country
code domains operating as generic TLDs.


4. The role of ICANN in country domains

ICANN (and IANA) should, as described above, have as little
involvement as possible in the direction of true country [code]
domains (i.e., category (iii)).  There is no particular reason why
these domains should be subject to ICANN regulation beyond the basic
principles of 1591 and associated arrangements needed to ensure
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 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
determining which claimant is the legitimate government of a country,
"international relations", and the reasons for not moving in that
particular direction are legion.

5. The role of governments

The history of IANA strategy in handling ccTLDs included three major
"things to avoid" considerations:

   * Never get involved in determining which entities were countries
   and which ones were not.

   * Never get involved in determining who was, or was not, the
   legitimate government of a country.  And, more generally, avoid
   deciding what entity --government, religion, commercial,
   academic, etc.-- has what legitimacy or rights.

   * If possible, never become involved in in-country disputes.
   Instead, very strongly encourage internal parties to work
   problems out among themselves.  At most, adopt a role as
   mediator and educator, rather than judge, unless abuses are very
   clear and clearly will not be settled by any internal mechanism.

All three considerations were obviously intended to avoid IANA's
being dragged into a political morass in which it had (and, I
suggest, has) no competence to resolve the issues and could only get
bogged down.  The first consideration was the most visible (and the
easiest) and was implemented by strict adherence to the ISO 3166
registered Country Code list.  If an entity had a code, it was
eligible to be registered with a TLD (although IANA was free to apply
other criteria-most of them stated in 1591).  If it did not, there
were no exceptions: the applicant's only recourse was a discussion
with the 3166 Registration Authority (now Maintenance Agency, often
known just as "3166/MA") or the UN Statistical Office (now Statistics
Bureau), not with IANA.  
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.
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, 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 purporting to be competent government
authorities asking for changes.  Some of them turned out later to not
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 or selection of
governments).

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
over the years, to avoid IANA's having to assume the role of judge
between conflicting parties.

Similar principles could be applied to the boundary between country-
code-based generic TLDs and country domains.  Different countries,
under different circumstances, might prefer to operate the ccTLD
either as a national service or as a profit center where the
"customers" were largely external.  Whatever decisions were made
historically, general Internet stability argues that changes should
not be made lightly.  At the same time, if a government wishes to
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 and for IANA to promptly
and efficiently carry out requests made by administrative contacts.


6. Implications for the current DNSO structure.

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.  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

[1] Postel, Jon.  Domain Name System Structure and Delegation,
    RFC 1591. USC Information Sciences Institute: March 1994.

[2] ISO 3166.  Codes for the identification of names of countries (??)

8. Acknowledgements and disclaimer

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,
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

This memo addresses the context for a set of administrative decisions
and procedures, and does not raise or address security issues.


10. Author's address

John C Klensin
1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140, USA
[e-mail]