Network Working Group                                        P Faltstrom
Internet-Draft                                             Cisco Systems
Expires: December 14, 2001                                 June 14, 2001


               Explanation of the registry/registrar concept
                 draft-faltstrom-registry-registrar-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 27, 2001.

Copyright Notice

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

Abstract

In discussions between IETF and ITU regarding administration of
services specificed according to RFC 2916 [ENUM], it is observed
that several documents talk about registries and registrars
in a way which is not in accordance with normal use in the DNS.

To help the discussions, IETF has via the ISOC Sector Membership
in ITU-T submitted this text to the Q.1/2 Rapporteurs meeting in
Oslo 25th - 29th June 2001.


.      Introduction

Many documents that have been circulated regarding ENUM issues in the
ITU-T have reflecte considerable confusion regarding DNS terminology.
In particular, there appears to be confusion and inconsistent use of
the terms "registry" and "registrar".  Also, when DNS "zones" are
hierarchically separated (at what is referred to as a "zone cut",
using a process technically known as "delegation"), the  and roles of
these parties appear to be further confused.

This document explains the terms, and argues that no attempt should
be made to redefine them in an ENUM world relative to other DNS
applications.


.      Zones and Delegations

A domain name can exist in only one zone in the DNS. This is
established in the definition of the DNS, where all domain names are
found by querying first a server for the root zone, and then
repeatedly querying servers in a recursive manner until the requested
record is either found, or an authoritative "NO" is received.

The recursion is based on a concept called delegations.

The root zone contains delegations to the various top-level domains
(TLDs) that exist.  Each of those TLDs may (and usually does) have
further delegations to servers that handle child (hierarchically
subsidiary) domains of those TLD's. This relationship can be repeated at
any place in the domain name hierarchy where a dot (".") is found:
I.e., any domain may be structured to have one or more delegated
subdomains, which may, in turn, have delegated subdomains, and so on,
and each of those subdomains may be administered by a different
individual or organization.

For a given subdomain, the delegation itself consists of DNS records
that identify the authoritative name servers for the subdomains.

The examples below assume that DNS records have not been "cached":
caching makes the process of finding a name more efficient (i.e.,
some steps may be bypassed since relevant information is already on
hand), but does change the basic logic of the system.

Example: The root zone contains a delegation for the domain INT,
which points at the name servers for the INT domain. In the INT zone,
delegations are present for subdomains of INT, such as ITU.INT. To
find the IP address for WWW.ITU.INT, one first queries the root
server.  The root server gives back pointers to the name servers for
INT.  When queried, they, in turn, give back pointers to the name
servers for ITU.INT. Those servers are then queried to obtain the IP
address.

.      Registry and Registrar

The organization that operates the DNS server(s) for a specific zone
is called a registry. To get any kind of information into a zone, one
has to contact that very registry. Given the way the DNS is designed
(see above), the registry function for a given zone is necessarily a
monopoly.

To allow competition regarding registration services the market has
introduced the concept of a "registrar".  The registrar is an
organization that can act, from a customer perspective, as a proxy
for the registry. So the customer (registrant) who wants names
registered in a specific zone does not approach the registry
directly, but instead contacts a registrar. The registrar collects
the necessary information, ensures that registrar-level conditions
are adhered to, and then passes the information to the registry and
verifies that the changes to the zone are performed.

This way the registry can be extremely lightweight (not doing more
than running a database and creating the zone file) while the
registrars do all the work (which might include invoicing the
registrant). The division of labor between registry and registrar is,
however, not fixed by the DNS protocols. It differs somewhat among
the various domain that use this scheme today (examples are the TLDs
"COM", "UK" and "SE").  And, since the division of responsibilities
between registrar and registry is, in general, a market-driven
mechanism rather than fundamental to the DNS, many zones (especially
deep in the hierarchy) do not use it.

.      Delegations

When requesting a delegation, the administrator of the child domain
becomes a registrant in the parent domain, and because of this, the
registrant contacts the registrar for the parent domain and requests
the delegation. The registrar passes information to the registry and
sees that the delegation is performed.

On the other hand, the delegation itself (at the zone file level) is
from the registry in the parent zone directly to the registry for the
child zone.

In other words, the registry at one level in the DNS tree is the
registrant of a domain name in the parent level.

The chain of zones is only between registries (and the zone files
they maintain), while the registrars (if they exist) only act on
behalf of registries as an aid to competition and greater registrant
administrative flexibility.

.      Services referenced by URIs according to RFC 2916

An end user (consumer) might have an email address at one email
service provider, a SIP address at an IP-Telephony provider, and an
E.164 number at a Telco. These might be three different service
providers, providing three different services. Each one of these
services can be identified by a URI (in a "NAPTR" DNS record).  The
protocol specified by RFC 2916 specifies that the necessary
information to access each of the services, using only the customer's
telco-based E.164 number, can be stored as URIs in the DNS.

Given that one can only have one registry for each zone in DNS, one
can only have one registry for the zone that holds the NAPTR records
for all three services.  At this level, as at every other level in
the DNS tree, one can, of course, have multiple registrars if
competition at that level and for those services is desired.

.      Tiers

The term "tier" has been introduced into ENUM discussions in ITU-T.
When that term is used together with the concepts of registry and
registrar, there is confusion about roles, i.e., which entities
perform which functions.

We have understood that the Tier definition is more closely bound to
functional layers than to names of particular entities or roles.

Tier 0: Management of the e164.arpa zone
Tier 1: Management of a CC
Tier 2: Management of a full E.164 number

Given this view on the specific Tiers, and the descriptions above,
one can conclude the following.

7.1     Tier 0

RFC 2916 defines in its IANA considerations section the following:

. IANA Considerations

   This memo requests that the IANA delegate the E164.ARPA domain
   following instructions to be provided by the IAB.  Names within this
   zone are to be delegated to parties according to the ITU
   recommendation E.164.  The names allocated should be hierarchic in
   accordance with ITU Recommendation E.164, and the codes should
   assigned in accordance with that Recommendation.

   Delegations in the zone e164.arpa (not delegations in delegated
   domains of e164.arpa) should be done after Expert Review, and the
   IESG will appoint a designated expert.

Through the IAB, the IETF has appointed RIPE-NCC as the operator of
the e164.arpa zone.  The IESG intends to appoint ITU, or an
ITU-designated subdivision or entity, the designated expert for
determining the contents and delegations of the top-level ("tier 0")
E164.ARPA zone.  The IAB and RIPE-NCC continue to wait for ITU to
come with suggestions on how this root is to be administrated between
the two organizations and how the registry of the zone (today
RIPE-NCC) is to verify whether an application is authoritative or not.

7.2     Tier 1

The national level.  As a national matter and choice, this level may
be organized into several registries or may be only a single
registry. Various examples of how Tier 1 can be organized for a given
country are described in other contributions to this meeting, but it
is important to remember that the selection of an organizational
approach and structure, as well as the particular operators involved,
are strictly national matters: the protocols, the DNS, and the
structure at Tier 0 permit a very broad range of options.

Also, whether there is single registry in Tier 1 for a telephony
country code, or if have more than one is used (e.g., additional
levels are introduced, such as one handling the CC, and then one for
each NDC) then the registries in child zones for the CC can contact a
registrar for the parent zone if competition is desired.

I.e. as is described in section 5, delegations are done directly from
parent registry to child registry, but the request for delegation
goes potentially from child registry via a registrar for the parent
zone to the parent registry.

7.3     Tier 2

At Tier 2 only the NAPTR resource records are stored in DNS. This
means that a registry that operates at Tier 2 operates a zone that
corresponds, according to RFC 2916, to the full subscriber number.
The registry can, as is described above, be accessed through
registrars if desired, but, most important, as is described in 6,
there should be equal access for all service providers who provide
services for the same customer in the zone. I.e. all service
providers must be able to enter information in the zone. This can
happen by having the consumer (registrant) take necessary information
from the service provider and giving it to the registry of his
choice, or a registrar for the same registry, or, in principle, by a
range of other alternatives.  As at Tier 1, how a given set of zones
and the associated administrative and registration arrangements are
structured is strictly a national matter.


.      Proposal

It is proposed that ITU-T in its documents very carefully verifies
that the terms "registry", "registrar", "domain" and "zone" are used
consistently and according to definitions in this document and
elsewhere in IETF standard definitions and specifications of the DNS.
Altered use of these terms, and introduction of new terms such as
"ENUM Service registry" with conflicting meanings, only adds
confusion and misunderstandings.  For example, the definition of
"ENUM Service registry" has very little to do with the definition of
the term "registry".


References


Authors' Address

   Patrik Faltstrom
   Cisco Systems Inc
   Arstaangsvagen 31J
   117 43 Stockholm
   Sweden

   Email: paf@cisco.com
   URI:   http://www.cisco.se


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, 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
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. 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 needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or 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.