ietf
[Top] [All Lists]

Re: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation

2006-03-06 01:32:32
All,

One more request on this.

In general if we just avoid replying to anyone who abuses the list, I guess
will make easier for all to silently discard those postings instead of
giving them extra lifetime.

Thanks for your understanding.

IETF Sergeant at arms



De: JORDI PALET MARTINEZ <jordi(_dot_)palet(_at_)consulintel(_dot_)es>
Responder a: <jordi(_dot_)palet(_at_)consulintel(_dot_)es>
Fecha: Mon, 06 Mar 2006 08:46:06 +0100
Para: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
Conversación: Beyond China's independent root-servers -- Expanding and Fixing
Domain Notation
Asunto: Re: Beyond China's independent root-servers -- Expanding and Fixing
Domain Notation

Hi all,

I will like to ask all to keep the spirit and wording of this thread (an of
course in general the IETF mail exploder) within an adequate tone and
respect towards the rest.

All the opinions should be respected also, but they should come with an
adequate "envelope" instead of abusive wording, that definitively will be
read as an insult by others and could generate and endless discussion.

So please, refrain of making any new "excess" in this list.

Thanks for your understanding !

IETF Sergeant at arms



De: Joe Baptista <baptista(_at_)cynikal(_dot_)net>
Organización: Planet Communications & Computing Facility
Responder a: <baptista(_at_)cynikal(_dot_)net>
Fecha: Fri, 03 Mar 2006 20:02:01 -0500
Para: Stephane Bortzmeyer <bortzmeyer(_at_)nic(_dot_)fr>
CC: IETF <ietf(_at_)ietf(_dot_)org>
Asunto: Re: Beyond China's independent root-servers -- Expanding and Fixing
Domain Notation

Stephane Bortzmeyer wrote:

There is nothing to do for the IETF or the "Internet technical
community" (whatever it is). The problem is 100 % political and should
be addressed in ICANN / WSIS / IGF / whatever but not in the IETF.

 

Good Lord - your spewing the crapola far and wide today.  Like I told
you in the governance conference.  Protocols are not political.  Least
you forget what I told you in the governance - here is my message to you
----- enjoy it - again.

Stephane Bortzmeyer wrote:

There are two different sorts of political problems on the
Internet. Those where a central governance is *mandatory* or things
simply stop to work. DNS root management and IP address allocation are
 

Where do you come up with this trash.  You either do not understand the
issues or your playing games.  Technical protocols are not political.
Technical protocols can not be mandated or their administration made
mandatory.  I can see it now - protocol police everywhere.

You can't mandate this - and you can't politicize it.  This whole issue
is about names and numbers.  And how do we manage names and numbers?
Answer - we use a database.

The only thing you require is a few simple rules to avoid conflicts -
and those rules have been written - I give you RFC 1591.  All one needs
to do is translate this from domains to TLDs.  Enjoy the light reading.

Network Working Group                                          J. Postel
Request for Comments: 1591                                           ISI
Category: Informational                                       March 1994


             Domain Name System Structure and Delegation


Status of this Memo

  This memo provides information for the Internet community.  This memo
  does not specify an Internet standard of any kind.  Distribution of
  this memo is unlimited.

1. Introduction

  This memo provides some information on the structure of the names in
  the Domain Name System (DNS), specifically the top-level domain
  names; and on the administration of domains.  The Internet Assigned
  Numbers Authority (IANA) is the overall authority for the IP
  Addresses, the Domain Names, and many other parameters, used in the
  Internet.  The day-to-day responsibility for the assignment of IP
  Addresses, Autonomous System Numbers, and most top and second level
  Domain Names are handled by the Internet Registry (IR) and regional
  registries.

2.  The Top Level Structure of the Domain Names

  In the Domain Name System (DNS) naming of computers there is a
  hierarchy of names.  The root of system is unnamed.  There are a set
  of what are called "top-level domain names" (TLDs).  These are the
  generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
  letter country codes from ISO-3166.  It is extremely unlikely that
  any other TLDs will be created.

  Under each TLD may be created a hierarchy of names.  Generally, under
  the generic TLDs the structure is very flat.  That is, many
  organizations are registered directly under the TLD, and any further
  structure is up to the individual organizations.

  In the country TLDs, there is a wide variation in the structure, in
  some countries the structure is very flat, in others there is
  substantial structural organization.  In some country domains the
  second levels are generic categories (such as, AC, CO, GO, and RE),
  in others they are based on political geography, and in still others,
  organization names are listed directly under the country code.  The
  organization for the US country domain is described in RFC 1480 [1].




Postel                                                          [Page 1]

RFC 1591      Domain Name System Structure and Delegation     March 1994


  Each of the generic TLDs was created for a general category of
  organizations.  The country code domains (for example, FR, NL, KR,
  US) are each organized by an administrator for that country.  These
  administrators may further delegate the management of portions of the
  naming tree.  These administrators are performing a public service on
  behalf of the Internet community.  Descriptions of the generic
  domains and the US country domain follow.

  Of these generic domains, five are international in nature, and two
  are restricted to use by entities in the United States.

  World Wide Generic Domains:

  COM - This domain is intended for commercial entities, that is
        companies.  This domain has grown very large and there is
        concern about the administrative load and system performance if
        the current growth pattern is continued.  Consideration is
        being taken to subdivide the COM domain and only allow future
        commercial registrations in the subdomains.

  EDU - This domain was originally intended for all educational
        institutions.  Many Universities, colleges, schools,
        educational service organizations, and educational consortia
        have registered here.  More recently a decision has been taken
        to limit further registrations to 4 year colleges and
        universities.  Schools and 2-year colleges will be registered
        in the country domains (see US Domain, especially K12 and CC,
        below).

  NET - This domain is intended to hold only the computers of network
        providers, that is the NIC and NOC computers, the
        administrative computers, and the network node computers.  The
        customers of the network provider would have domain names of
        their own (not in the NET TLD).

  ORG - This domain is intended as the miscellaneous TLD for
        organizations that didn't fit anywhere else.  Some non-
        government organizations may fit here.

  INT - This domain is for organizations established by international
        treaties, or international databases.

  United States Only Generic Domains:

  GOV - This domain was originally intended for any kind of government
        office or agency.  More recently a decision was taken to
        register only agencies of the US Federal government in this
        domain.  State and local agencies are registered in the country



Postel                                                          [Page 2]

RFC 1591      Domain Name System Structure and Delegation     March 1994


        domains (see US Domain, below).

  MIL - This domain is used by the US military.

  Example country code Domain:

  US - As an example of a country domain, the US domain provides for
       the registration of all kinds of entities in the United States
       on the basis of political geography, that is, a hierarchy of
       <entity-name>.<locality>.<state-code>.US.  For example,
       "IBM.Armonk.NY.US".  In addition, branches of the US domain are
       provided within each state for schools (K12), community colleges
       (CC), technical schools (TEC), state government agencies
       (STATE), councils of governments (COG),libraries (LIB), museums
       (MUS), and several other generic types of entities (see RFC 1480
       for details [1]).

  To find a contact for a TLD use the "whois" program to access the
  database on the host rs.internic.net.  Append "-dom" to the name of
  TLD you are interested in.  For example:

                      whois -h rs.internic.net us-dom
     or
                      whois -h rs.internic.net edu-dom

3.  The Administration of Delegated Domains

  The Internet Assigned Numbers Authority (IANA) is responsible for the
  overall coordination and management of the Domain Name System (DNS),
  and especially the delegation of portions of the name space called
  top-level domains.  Most of these top-level domains are two-letter
  country codes taken from the ISO standard 3166.

  A central Internet Registry (IR) has been selected and designated to
  handled the bulk of the day-to-day administration of the Domain Name
  System.  Applications for new top-level domains (for example, country
  code domains) are handled by the IR with consultation with the IANA.
  The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
  ORG, NET, and GOV are registered by the Internet Registry at the
  InterNIC.  The second level domains in the MIL are registered by the
  DDN registry at NIC.DDN.MIL.  Second level names in INT are
  registered by the PVM at ISI.EDU.

  While all requests for new top-level domains must be sent to the
  Internic (at hostmaster(_at_)internic(_dot_)net), the regional registries 
are
  often enlisted to assist in the administration of the DNS, especially
  in solving problems with a country administration.  Currently, the
  RIPE NCC is the regional registry for Europe and the APNIC is the



Postel                                                          [Page 3]

RFC 1591      Domain Name System Structure and Delegation     March 1994


  regional registry for the Asia-Pacific region, while the INTERNIC
  administers the North America region, and all the as yet undelegated
  regions.

     The contact mailboxes for these regional registries are:

        INTERNIC        hostmaster(_at_)internic(_dot_)net
        APNIC           hostmaster(_at_)apnic(_dot_)net
        RIPE NCC        ncc(_at_)ripe(_dot_)net

  The policy concerns involved when a new top-level domain is
  established are described in the following.  Also mentioned are
  concerns raised when it is necessary to change the delegation of an
  established domain from one party to another.

  A new top-level domain is usually created and its management
  delegated to a "designated manager" all at once.

  Most of these same concerns are relevant when a sub-domain is
  delegated and in general the principles described here apply
  recursively to all delegations of the Internet DNS name space.

  The major concern in selecting a designated manager for a domain is
  that it be able to carry out the necessary responsibilities, and have
  the ability to do a equitable, just, honest, and competent job.

  1) The key requirement is that for each domain there be a designated
     manager for supervising that domain's name space.  In the case of
     top-level domains that are country codes this means that there is
     a manager that supervises the domain names and operates the domain
     name system in that country.

     The manager must, of course, be on the Internet.  There must be
     Internet Protocol (IP) connectivity to the nameservers and email
     connectivity to the management and staff of the manager.

     There must be an administrative contact and a technical contact
     for each domain.  For top-level domains that are country codes at
     least the administrative contact must reside in the country
     involved.

  2) These designated authorities are trustees for the delegated
     domain, and have a duty to serve the community.

     The designated manager is the trustee of the top-level domain for
     both the nation, in the case of a country code, and the global
     Internet community.




Postel                                                          [Page 4]

RFC 1591      Domain Name System Structure and Delegation     March 1994


     Concerns about "rights" and "ownership" of domains are
     inappropriate.  It is appropriate to be concerned about
     "responsibilities" and "service" to the community.

  3) The designated manager must be equitable to all groups in the
     domain that request domain names.

     This means that the same rules are applied to all requests, all
     requests must be processed in a non-discriminatory fashion, and
     academic and commercial (and other) users are treated on an equal
     basis.  No bias shall be shown regarding requests that may come
     from customers of some other business related to the manager --
     e.g., no preferential service for customers of a particular data
     network provider.  There can be no requirement that a particular
     mail system (or other application), protocol, or product be used.

     There are no requirements on subdomains of top-level domains
     beyond the requirements on higher-level domains themselves.  That
     is, the requirements in this memo are applied recursively.  In
     particular, all subdomains shall be allowed to operate their own
     domain name servers, providing in them whatever information the
     subdomain manager sees fit (as long as it is true and correct).

  4) Significantly interested parties in the domain should agree that
     the designated manager is the appropriate party.

     The IANA tries to have any contending parties reach agreement
     among themselves, and generally takes no action to change things
     unless all the contending parties agree; only in cases where the
     designated manager has substantially mis-behaved would the IANA
     step in.

     However, it is also appropriate for interested parties to have
     some voice in selecting the designated manager.

     There are two cases where the IANA and the central IR may
     establish a new top-level domain and delegate only a portion of
     it: (1) there are contending parties that cannot agree, or (2) the
     applying party may not be able to represent or serve the whole
     country.  The later case sometimes arises when a party outside a
     country is trying to be helpful in getting networking started in a
     country -- this is sometimes called a "proxy" DNS service.

     The Internet DNS Names Review Board (IDNB), a committee
     established by the IANA, will act as a review panel for cases in
     which the parties can not reach agreement among themselves.  The
     IDNB's decisions will be binding.




Postel                                                          [Page 5]

RFC 1591      Domain Name System Structure and Delegation     March 1994


  5) The designated manager must do a satisfactory job of operating the
     DNS service for the domain.

     That is, the actual management of the assigning of domain names,
     delegating subdomains and operating nameservers must be done with
     technical competence.  This includes keeping the central IR (in
     the case of top-level domains) or other higher-level domain
     manager advised of the status of the domain, responding to
     requests in a timely manner, and operating the database with
     accuracy, robustness, and resilience.

     There must be a primary and a secondary nameserver that have IP
     connectivity to the Internet and can be easily checked for
     operational status and database accuracy by the IR and the IANA.

     In cases when there are persistent problems with the proper
     operation of a domain, the delegation may be revoked, and possibly
     delegated to another designated manager.

  6) For any transfer of the designated manager trusteeship from one
     organization to another, the higher-level domain manager (the IANA
     in the case of top-level domains) must receive communications from
     both the old organization and the new organization that assure the
     IANA that the transfer in mutually agreed, and that the new
     organization understands its responsibilities.

     It is also very helpful for the IANA to receive communications
     from other parties that may be concerned or affected by the
     transfer.

4. Rights to Names

  1) Names and Trademarks

     In case of a dispute between domain name registrants as to the
     rights to a particular name, the registration authority shall have
     no role or responsibility other than to provide the contact
     information to both parties.

     The registration of a domain name does not have any Trademark
     status.  It is up to the requestor to be sure he is not violating
     anyone else's Trademark.

  2) Country Codes

     The IANA is not in the business of deciding what is and what is
     not a country.




Postel                                                          [Page 6]

RFC 1591      Domain Name System Structure and Delegation     March 1994


     The selection of the ISO 3166 list as a basis for country code
     top-level domain names was made with the knowledge that ISO has a
     procedure for determining which entities should be and should not
     be on that list.

5. Security Considerations

  Security issues are not discussed in this memo.

6. Acknowledgements

  Many people have made comments on draft version of these descriptions
  and procedures.  Steve Goldstein and John Klensin have been
  particularly helpful.

7. Author's Address

  Jon Postel
  USC/Information Sciences Institute
  4676 Admiralty Way
  Marina del Rey, CA  90292

  Phone: 310-822-1511
  Fax:   310-823-6714
  EMail: Postel(_at_)ISI(_dot_)EDU

7. References

  [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
      USC/Information Sciences Institute, June 1993.

  [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
      USC/Information Sciences Institute, July 1992.

  [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
      13, RFC 1034, USC/Information Sciences Institute, November 1987.

  [4] Mockapetris, P., "Domain Names - Implementation and
      Specification", STD 13, RFC 1035, USC/Information Sciences
      Institute, November 1987.

  [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
      974, CSNET CIC BBN, January 1986.

  [7] Braden, R., Editor, "Requirements for Internet Hosts --
      Application and Support", STD 3, RFC 1123, Internet Engineering
      Task Force, October 1989.




Postel                                                          [Page 7]







_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware that
any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware that
any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.






**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>