rfc3071.txt

bind 9.3结合mysql数据库


RFC 3071          Reflections on the DNS and RFC 1591      February 2001


   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 and careful adherence (see
   below) 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 additional 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.






Klensin                      Informational                      [Page 6]

RFC 3071          Reflections on the DNS and RFC 1591      February 2001


   There are actually five ccTLD exceptions to the strict rules.  One,
   "UK", is historical: it predates the adoption of ISO 3166 for this
   purpose.  The others --Ascension Island, Guernsey, Isle of Man, and
   Jersey --are arguably, at least in retrospect, just mistakes.
   Regardless of the historical reasons (about which there has been much
   speculation), it is almost certainly the case that the right way to
   handle mistakes of this sort is to acknowledge them and move on,
   rather than trying to use them as precedents to justify more
   mistakes.

   This, obviously, is also the argument against use of the "reserved"
   list (technically internal to the 3166 maintenance activity, and not
   part of the Standard): 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).






Klensin                      Informational                      [Page 7]

RFC 3071          Reflections on the DNS and RFC 1591      February 2001


   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
   ICANN's Government Advisory Committee (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 ICANN 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, J., "Domain Name System Structure and Delegation", RFC
       1591, March 1994.

   [2] ISO 3166. ISO 3166-1. Codes for the representation of names of
       countries and their subdivisions - Part 1: Country codes (1997).






Klensin                      Informational                      [Page 8]

RFC 3071          Reflections on the DNS and RFC 1591      February 2001


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.  Cord Wischhoefer, of the ISO 3166/MA, was also kind
   enough to look at the draft and supplied some useful details.  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

   EMail: [e-mail]

























Klensin                      Informational                      [Page 9]

RFC 3071          Reflections on the DNS and RFC 1591      February 2001


11. Full Copyright Statement

   Copyright (C) The Internet Society 2001. All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others provided that the above copyright notice and this paragraph
   are included on all such copies.  However, this document itself may
   not be modified in any way, such as by removing the copyright notice
   or references to the Internet Society or other Internet
   organizations, except as required to translate it into languages
   other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR  IMPLIED, INCLUDING
   BUT NOT  LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY  IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

























Klensin                      Informational                     [Page 10]