Subject: [Ietf-not43] requirements diffs

From: [email-masked] (Andrew Newton)
Date: Mon, 05 Aug 2002 12:17:04 -0400

This is a multi-part message in MIME format.
--------------10D531E406820549FCF3A484
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I know that the first thing everyone did with their Monday morning was
to download the latest requirements draft from the repository and scan
it in detail for what changed.  After all, the only thing more fun than
talking about what your are going to do is talking about talking about
what your are going to do.

So to make the task easier, I've attached a "more-human-readable" diff
of the draft.  Also attached is an HTML version of the draft for people
wanting to use this new fangled thing called "hyper-linking" to
cross-reference sections.

-andy
--------------10D531E406820549FCF3A484
Content-Type: text/plain; charset=us-ascii;
 name="crisp-req-ann.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="crisp-req-ann.diff"

Abstract

   Internet registries expose administrative and operational data via
   varying directory services. This document defines functional
   requirements for the directory services of domain registries and the
   common base requirements for extending the use of these services for
   other types of Internet registries.

---------------------

2.4.6 Domain Registrants

   Entities given authority over a domain via purchase, lease, or grant
   from a domain registry, either directly or via the services of a
   domain registrar.

---------------------

3. Functional Requirements

   Functional requirements describe an overall need or process for
   which the directory service is used by an Internet registry to
   fulfill its obligations to provide access to its respective
   customers, members, or other constituents. This section makes
   reference to terms and definitions declared in Appendix A. This
   section makes use of the term "service" to denote the set of
   functions to be provided by, and the expected behavior of, software
   built to meet these requirements in one or more protocols.

   These requirements are for the purpose of designing a technical
   specification. The words used in this section are for compliance
   with RFC2119[8], do not reference or specify policy, and speak only
   to the capabilities in the derived technology.

---------------------

3.1.8 Query of Access Levels

   If a query cannot yield a valid response due to insufficient
   permissions, the service MUST provide the client with an error
   response indicating this condition. The service SHOULD NOT provide a
   mechanism allowing a client to determine if a query will be denied
   before the query is submitted.

   It is the intent of this requirement for clients to learn of
   inadequate permission status for a query only after the query has
   been submitted. Operating modes allowing a client to predetermine
   the queries that will or will not be denied are not encouraged for
   security considerations.

---------------------

3.2.4 Domain Registrant Search

   The service MUST provide the capability of searching for registrants
   by exact name match or a reasonable name subset. The service MAY
   provide limits to the number of results from this search to
   alleviate performance or comply with Section 3.1.1. If the service
   limits the number of results from this search to alleviate
   performance, it MUST provide the client with a response indicating
   this condition. If the service limits the number of results from
   this search to comply with Section 3.1.1, it MUST NOT provide the
   client with a response indicating this condition.

   The service MUST provide a mechanism to distribute this search
   across all applicable domain registries and registrars. The service
   SHOULD have a means to narrow the scope of a search to a specific
   TLD. The service MUST be able to specify to the client an empty
   result set should the search yield no results.

---------------------

3.2.5 Domain Information Lookup

   The service MUST provide access to operational and social data
   specific to a domain given the domain's fully qualified name (FQDN).
   This information SHOULD include the following:

   o  activation status

   o  registrant name and contact data

   o  hosting nameservers

   o  technical, billing or other entity types associate with the
      domain and their relevant contact data, if any exist

   o  the name of or a reference to the registry delegating the domain

   o  the name of or a reference to the registrar for the domain, if
      one exists

---------------------

3.2.9 Domain Name Search

   The service MUST allow searching for domains by exact name match or
   a reasonable subset of a domain name. The service MAY provide limits
   to the number of results from this search to alleviate performance
   or comply with Section 3.1.1. If the service limits the number of
   results from this search to alleviate performance, it MUST provide
   the client with a response indicating this condition. If the service
   limits the number of results from this search to comply with Section
   3.1.1, it MUST NOT provide the client with a response indicating
   this condition.

   The service MUST provide a mechanism to distribute this search
   across all applicable domain registries and registrars. There should
   be a means to narrow this search based on a TLD. 

   The search mechanism SHOULD provide for differences in domain names
   between the native representation and the canonical form existing in
   the registry.

---------------------

3.2.10 DNS Label Referencing

   The service MUST use DNS[2] to determine the authoritative source of
   information about domain names. It is the intention of this
   requirement that a client be able to determine via DNS and query the
   servers or set of servers of the domain registry delegating the
   domain name, the domain registrar responsible for registering the
   domain name if one is applicable, and the domain registrant of the
   domain name. The service SHOULD provide procedures or mechanisms to
   allow this determination if it cannot be done using DNS.

---------------------

3.2.11 Distribution for Domain Registry Types

   The service MUST allow for the various registration distribution
   models of domain registry types described in Section 2.1.1 while
   complying with Section 3.1.7.

---------------------

4. Feature Requirements

   Feature requirements describe the perceived need derived from the
   functional requirements for specific technical criteria of the
   directory service. This section makes references to terms and
   definitions declared in Appendix A . This section uses the term
   "service" to denote the set of features to be provided by, and the
   expected behavior of, software built to meet these requirements in
   one or more protocols.

   These requirements are for the purpose of designing a technical
   specification. The words used in this section are for compliance
   with RFC2119[8], do not reference or specify policy, and speak only
   to the capabilities in the derived technology.

--------------10D531E406820549FCF3A484
Content-Type: text/html; charset=us-ascii;
 name="draft-ietf-crisp-requirements-00.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-crisp-requirements-00.html"

<html><head><title>Cross Registry Internet Service Protocol (CRISP) Requirements</title>
<STYLE type='text/css'>
    .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right;
             font-family: helvetica, arial, sans-serif }
    .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right;
                  font-family: helvetica, arial, sans-serif }
    p.copyright { color: #000000; font-size: 10px;
                  font-family: verdana, charcoal, helvetica, arial, sans-serif }
    p { margin-left: 2em; margin-right: 2em; }
    ol { margin-left: 2em; margin-right: 2em; }
    ul.text { margin-left: 2em; margin-right: 2em; }
    pre { margin-left: 3em; color: #333333 }
    ul.toc { color: #000000; line-height: 16px;
             font-family: verdana, charcoal, helvetica, arial, sans-serif }
    H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif }
    H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif }
    TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top }
    TD.author-text { color: #000000; font-size: 10px;
                     font-family: verdana, charcoal, helvetica, arial, sans-serif }
    TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif }
    A:link { color: #990000; font-size: 10px; text-transform: uppercase; font-weight: bold;
             font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
    A:visited { color: #333333; font-weight: bold; font-size: 10px; text-transform: uppercase;
                font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
    A:name { color: #333333; font-weight: bold; font-size: 10px; text-transform: uppercase;
             font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
    .link2 { color:#ffffff; font-weight: bold; text-decoration: none;
             font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
             font-size: 9px }
    .RFC { color:#666666; font-weight: bold; text-decoration: none;
           font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
           font-size: 9px }
    .hotText { color:#ffffff; font-weight: normal; text-decoration: none;
               font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
               font-size: 9px }
</style>
</head>
<body bgcolor="#ffffff"text="#000000" alink="#000000" vlink="#666666" link="#990000">
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1">
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Network Working Group</td><td width="33%" bgcolor="#666666" class="header">A. Newton</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">VeriSign, Inc.</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: January 29, 2003</td><td width="33%" bgcolor="#666666" class="header">July 31, 2002</td></tr>
</table></td></tr></table>
<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">Cross Registry Internet Service Protocol (CRISP) Requirements</span></b></font></div>
<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-ietf-crisp-requirements-00</span></b></font></div>
<font face="verdana, helvetica, arial, sans-serif" size="2">

<h3>Status of this Memo</h3>
<p>
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p>
<p>
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.</p>
<p>
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."</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on January 29, 2003.</p>

<h3>Copyright Notice</h3>
<p>
Copyright (C) The Internet Society (2002). All Rights Reserved.</p>

<h3>Abstract</h3>

<p>
Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries.
</p>
<a name="toc"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Table of Contents</h3>
<ul compact class="toc">
<b><a href="#background">1.</a>&nbsp;
Background<br></b>
<b><a href="#communities">2.</a>&nbsp;
Internet Registry Communities<br></b>
<b><a href="#dom-registries">2.1</a>&nbsp;
Domain Name System Registries<br></b>
<b><a href="#domain-registries">2.1.1</a>&nbsp;
Domain Registries<br></b>
<b><a href="#domain-registrars">2.1.2</a>&nbsp;
Domain Registrars<br></b>
<b><a href="#other-registries">2.2</a>&nbsp;
Other Registries<br></b>
<b><a href="#rir">2.2.1</a>&nbsp;
Regional Internet Registries<br></b>
<b><a href="#lir">2.2.2</a>&nbsp;
Local Internet Registries<br></b>
<b><a href="#irr">2.2.3</a>&nbsp;
Internet Routing Registries<br></b>
<b><a href="#icc-reg">2.2.4</a>&nbsp;
Incident Coordination Contact Registries<br></b>
<b><a href="#nerr-reg">2.2.5</a>&nbsp;
Network Edge Resource Registries<br></b>
<b><a href="#implementers">2.3</a>&nbsp;
Implementers<br></b>
<b><a href="#end-users">2.4</a>&nbsp;
End Users<br></b>
<b><a href="#isp">2.4.1</a>&nbsp;
Service Providers and Network Operators<br></b>
<b><a href="#ipr">2.4.2</a>&nbsp;
Intellectual Property Holders<br></b>
<b><a href="#law">2.4.3</a>&nbsp;
Law Enforcement<br></b>
<b><a href="#ca">2.4.4</a>&nbsp;
Certificate Authorities<br></b>
<b><a href="#dns-users">2.4.5</a>&nbsp;
DNS Users<br></b>
<b><a href="#domain-registrants">2.4.6</a>&nbsp;
Domain Registrants<br></b>
<b><a href="#other-actors">2.5</a>&nbsp;
Other Actors<br></b>
<b><a href="#functional-requirements">3.</a>&nbsp;
Functional Requirements<br></b>
<b><a href="#common-functions">3.1</a>&nbsp;
Base Functions<br></b>
<b><a href="#mining-prev">3.1.1</a>&nbsp;
Mining Prevention<br></b>
<b><a href="#min-tech-reinvent">3.1.2</a>&nbsp;
Minimal Technical Reinvention<br></b>
<b><a href="#pred-stand-expr">3.1.3</a>&nbsp;
Standard and Extensible Schemas<br></b>
<b><a href="#level-access">3.1.4</a>&nbsp;
Level of Access<br></b>
<b><a href="#client-proc">3.1.5</a>&nbsp;
Client Processing<br></b>
<b><a href="#entity-ref">3.1.6</a>&nbsp;
Entity Referencing<br></b>
<b><a href="#decentral">3.1.7</a>&nbsp;
Decentralization<br></b>
<b><a href="#queyr-access">3.1.8</a>&nbsp;
Query of Access Levels<br></b>
<b><a href="#domain-functions">3.2</a>&nbsp;
Domain Specific Functions<br></b>
<b><a href="#contact-lookup">3.2.1</a>&nbsp;
Contact Lookup<br></b>
<b><a href="#ns-lookup">3.2.2</a>&nbsp;
Nameserver Lookup<br></b>
<b><a href="#dom-stat-lookup">3.2.3</a>&nbsp;
Domain Status Lookup<br></b>
<b><a href="#dom-registrant-search">3.2.4</a>&nbsp;
Domain Registrant Search<br></b>
<b><a href="#dom-info-lookup">3.2.5</a>&nbsp;
Domain Information Lookup<br></b>
<b><a href="#ns-search">3.2.6</a>&nbsp;
Nameserver Search<br></b>
<b><a href="#escrow">3.2.7</a>&nbsp;
Escrow Support<br></b>
<b><a href="#auth-dist">3.2.8</a>&nbsp;
Authentication Distribution<br></b>
<b><a href="#dom-name-search">3.2.9</a>&nbsp;
Domain Name Search<br></b>
<b><a href="#domain-dns-ref">3.2.10</a>&nbsp;
DNS Label Referencing<br></b>
<b><a href="#dist-for-domain-types">3.2.11</a>&nbsp;
Distribution for Domain Registry Types<br></b>
<b><a href="#feature-requirements">4.</a>&nbsp;
Feature Requirements<br></b>
<b><a href="#client-auth">4.1</a>&nbsp;
Client Authentication<br></b>
<b><a href="#referrals">4.2</a>&nbsp;
Referrals<br></b>
<b><a href="#common-ref">4.3</a>&nbsp;
Common Referral Mechanism<br></b>
<b><a href="#structure">4.4</a>&nbsp;
Structured Queries and Responses<br></b>
<b><a href="#existing-schema">4.5</a>&nbsp;
Existing Schema Language<br></b>
<b><a href="#defined-schemas">4.6</a>&nbsp;
Defined Schemas<br></b>
<b><a href="#serialization">4.7</a>&nbsp;
Serialization Definition<br></b>
<b><a href="#internationalization-con">5.</a>&nbsp;
Internationalization Considerations<br></b>
<b><a href="#iana-con">6.</a>&nbsp;
IANA Considerations<br></b>
<b><a href="#security-con">7.</a>&nbsp;
Security Considerations<br></b>
<b><a href="#rfc.references">&#167;</a>&nbsp;
References<br></b>
<b><a href="#rfc.authors">&#167;</a>&nbsp;
Author's Address<br></b>
<b><a href="#glassory">A.</a>&nbsp;
Glossary<br></b>
<b><a href="#acknowledgements">B.</a>&nbsp;
Acknowledgements<br></b>
<b><a href="#forums">B.1</a>&nbsp;
Forums<br></b>
<b><a href="#working-group">B.2</a>&nbsp;
Working Group<br></b>
<b><a href="#contributions">B.3</a>&nbsp;
Contributions<br></b>
<b><a href="#rfc.copyright">&#167;</a>&nbsp;
Full Copyright Statement<br></b>
</ul>
<br clear="all">

<a name="background"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>1.&nbsp;Background</h3>

<p>
The expansion and growth of the Internet has seen the registry function of a traditionally centralized and managed Network Information Center become the responsibility of various autonomous, functionally disparate, and globally distributed Internet registries. With the broadening number of Internet registries, the uses of their administrative directory services have expanded from the original and traditional use of the <a href="#RFC0954">whois</a>[4] protocol to include the use of whois outside the scope of its specification, formal and informal definitions of syntax, undocumented security mechanisms, the use of other protocols, such as <a href="#RFC2167">rwhois</a>[3], to fulfill other needs, and proposals for the use of other technologies such as <a href="#RFC2251">LDAP</a>[1] and XML.
</p>

<p>
The scope of the requirements captured in this document relate to the directory services of Internet registries and their related communities (<a href="#implementers">Implementers</a>,<a href="#end-users">End Users</a>, and <a href="#other-actors">Other Actors</a>). This scoping specifically targets the requirements of <a href="#dom-registries">domain name registries</a> while acknowledging extensibility needs for possible future support of the requirements for <a href="#other-registries">other registry</a> types. The requirements are of both the current use of these directory services and the desired functionality based on input from relevant <a href="#forums">forums</a>. These requirements are not specific to any protocol. Terms used in the definition of requirements in this document may be found in the <a href="#glassory">glossary</a>.
</p>

<p>
The requirements captured in this document are for the purpose of designing technical specifications. The words used in this document for compliance with <a href="#RFC2119">RFC2119</a>[8] do not reference or specify policy and speak only to the capabilities in the derived technology. The scope of the requirements in this document are also restricted to access of data from Internet registries. Requirements for modification, addition, or provisioning of data in Internet registries are out of scope.
</p>

<a name="communities"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>2.&nbsp;Internet Registry Communities</h3>

<p>
The Internet registries are composed of various communities which provide scope for the requirements in this document. These communities can be generalized into the following categories: registries, registrars, implementers, end-users, and other actors.
</p>

<h4><a name="dom-registries">2.1</a>&nbsp;Domain Name System Registries</h4>

<h4><a name="domain-registries">2.1.1</a>&nbsp;Domain Registries</h4>

<p>
Domain registries are responsible for the registration of domains for use with <a href="#RFC1035">DNS</a>[2] and forward lookups (i.e. does not include the IN-ADDR.ARPA or IP6.ARPA domains). These registries have typically served two main domain functions: as the registry for a gTLD or as a registry for a ccTLD. In some instances, one entity will operate multiple TLD's, both of the gTLD and ccTLD type. A gTLD or ccTLD domain registry operator may be a governmental entity, non-governmental, non-commercial entity, or a commercial entity.
</p>

<p>
Some ccTLD's have second-level domain registrations similar in nature to gTLD's or have distinctly separate entities operating second-level domain registries similar in nature to gTLD's within the ccTLD.
</p>

<p>
Domain registries usually follow one of two models for conducting registrations of domains. The "thick" model is the more traditional model. In a "thick" domain registry, the registry contains both the operational data for the domain and the contact or <a href="#glassory">social data</a> for the domain. In this model, the registry is typically the interface to the domain registrant but may also interface with the domain registrant through domain registrars. The "thin" model domain registry contains only operational data for domains. In the "thin" model, contact or social data for the domain are maintained by a domain registrar.
</p>

<p>
Domain registries not described in this section (<a href="#domain-registries">Domain Registries</a>) are not the subject of this document and may have requirements that are out of scope for this subject matter.
</p>

<h4><a name="domain-registrars">2.1.2</a>&nbsp;Domain Registrars</h4>

<p>
Domain registrars accept domain registrations from registrants on behalf of domain registries, both "thick" and "thin". In a "thin" model registry/registrar system, a domain registrar maintains the contact and social data of a domain while the registry maintains the operational data of a domain. In a "thick" model registry/registrar system, a domain registrar passes both the operational data and contact data to the registry. Domain registrars may register a domain on behalf of a registrant in more than one domain registry.
</p>

<h4><a name="other-registries">2.2</a>&nbsp;Other Registries</h4>

<h4><a name="rir">2.2.1</a>&nbsp;Regional Internet Registries</h4>

<p>
Regional Internet Registries (RIR's) administer the allocation of IP address space and autonomous system numbers. Each RIR serves a specific geographic region, and collectively they service the entire Internet. Each RIR is a membership-based, non-profit organization that facilitates and implements global addressing policy based on the direction of their regional community. 
</p>

<h4><a name="lir">2.2.2</a>&nbsp;Local Internet Registries</h4>

<p>
Local Internet Registries (LIR's) and National Internet Registries (NIR's) are sub-registries of RIR's and coordinate the same functions of the RIR's for smaller, more specific geographic regions, sovereign nations, and localities.
</p>

<h4><a name="irr">2.2.3</a>&nbsp;Internet Routing Registries</h4>

<p>
Internet Routing Registries are routing policy databases. Their purpose is to provide information helpful in administering Internet routers. Frequently, the syntax and contents are defined by <a href="#RFC2622">RPSL</a>[5]. 
</p>

<p>
IRR's are operated by academic, commercial, governmental, and other types of organizations, including several of the RIR's. The contents of the databases vary and reflect the needs of the users directly served (e.g. an ISP may look up route entries added by their customers to decide whether to accept specific route advertisements they receive). 
</p>

<p>
Unlike RIR and domain registry data, IRR data is often duplicated between separate organizations. The IRR data has the unique characteristics of being largely available through other sources (i.e. it is advertised by the Internet routing protocols) and most often having a common data format, RPSL. 
</p>

<h4><a name="icc-reg">2.2.4</a>&nbsp;Incident Coordination Contact Registries</h4>

<p>
Incident coordination contact registries allow operators of network resources such as network infrastructure, network names, or network services to register contact information for the purpose of providing a means of incident notification. Using this type of registry, an operators of network resources are provided information for contacting the operator of another network resource from which an incident may be occurring.
</p>

<h4><a name="nerr-reg">2.2.5</a>&nbsp;Network Edge Resource Registries</h4>

<p>
Network edge resource registries provide specific information about "edge" resources. They are administered by the operators of the resources. Examples of such registries are <a href="#RFC2167">rwhois</a>[3] servers operated by networks to describe the assignment of address space allocated by RIR's or LIR's and <a href="#RFC0954">whois</a>[4] servers operated by networks to specifically announce routing policy of that network.
</p>

<h4><a name="implementers">2.3</a>&nbsp;Implementers</h4>

<p>
Implementers of client software are often either affiliated with large network operators, registry operators, or commercial entities offering value-added services, or are general citizens of the Internet. Much of the client software for use with the directory services of Internet registries is either freely available, open source, or both, or available as a service. Implementers of server software are often affiliated with operators or commercial entities specializing in the out-sourcing of development for Internet registries.
</p>

<h4><a name="end-users">2.4</a>&nbsp;End Users</h4>

<h4><a name="isp">2.4.1</a>&nbsp;Service Providers and Network Operators</h4>

<p>
Service providers and network operators provide connectivity, routing, and naming services to many other entities, some commercial and some non-commercial, both large and small. Their operational and administrative staff often interact with Internet registries on behalf of other end-users. Service providers and network operators interact with all of the Internet registry operators outlined in this document on a frequent and consistent basis. For example, network operators use the directory services of Internet registries to determine contact information for network resources that have technical problems.
</p>

<h4><a name="ipr">2.4.2</a>&nbsp;Intellectual Property Holders</h4>

<p>
Intellectual Property Holders have legal rights to the use of domain names based on copyright and trademark laws of various governments. They use the directory services of Internet registries, mostly domain registries and registrars, for purposes of maintaining and defending claims to domain names consistent with applicable laws and regulations.
</p>

<h4><a name="law">2.4.3</a>&nbsp;Law Enforcement</h4>

<p>
Law enforcement agencies use the directory services of Internet registries to find information used to carry out the enforcement of laws within their jurisdictions.
</p>

<h4><a name="ca">2.4.4</a>&nbsp;Certificate Authorities</h4>

<p>
Certificate authorities use the directory services of Internet registries as part of their verification process when issuing certificates for Internet named hosts.
</p>

<h4><a name="dns-users">2.4.5</a>&nbsp;DNS Users</h4>

<p>
Users of the Internet have client software that resolves domain names to IP addresses. Often when trouble occurs in the resolution process of DNS, these users trouble shoot system problems with the aid of information from the directory services of Internet registries.
</p>

<h4><a name="domain-registrants">2.4.6</a>&nbsp;Domain Registrants</h4>

<p>
Entities given authority over a domain via purchase, lease, or grant from a domain registry, either directly or via the services of a domain registrar.
</p>

<h4><a name="other-actors">2.5</a>&nbsp;Other Actors</h4>

<p>
Requirements must also consider the positions and policies of other actors on the use of Internet registry directory services by other actors. These actors include governments, non-governmental policy-setting bodies, and other non-governmental organizations.
</p>

<a name="functional-requirements"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>3.&nbsp;Functional Requirements</h3>

<p>
Functional requirements describe an overall need or process for which the directory service is used by an Internet registry to fulfill its obligations to provide access to its respective customers, members, or other constituents. This section makes reference to terms and definitions declared in <a href="#glassory">Glossary</a>. This section makes use of the term "service" to denote the set of functions to be provided by, and the expected behavior of, software built to meet these requirements in one or more protocols.
</p>

<p>
These requirements are for the purpose of designing a technical specification. The words used in this section are for compliance with <a href="#RFC2119">RFC2119</a>[8], do not reference or specify policy, and speak only to the capabilities in the derived technology.
</p>

<h4><a name="common-functions">3.1</a>&nbsp;Base Functions</h4>

<p>
This section describes basic service requirements for an Internet registry service for any of the registries (<a href="#dom-registries">domain name registries</a> and <a href="#other-registries">other registries</a>). Additional requirements, specific to domain registries, are described in <a href="#domain-functions">Domain Specific Functions</a>.
</p>

<h4><a name="mining-prev">3.1.1</a>&nbsp;Mining Prevention</h4>

<p>
The service MUST have a mechanism to limit the amount of data that may be accessed. The service MAY have different limits for different types of data, as well as for authenticated and non-authenticated entities. The service SHOULD be capable of expressing to the client these access limitations based on queries per session per unit of time, queries per source IP address per unit of time, and total queries from all client sessions per unit of time. The service SHOULD be able to limit the amount of data based on the above types of limitations.
</p>

<h4><a name="min-tech-reinvent">3.1.2</a>&nbsp;Minimal Technical Reinvention</h4>

<p>
The service MUST NOT employ unique technology solutions for all aspects and layers above the network and transport layers of the total service solution and SHOULD make use of existing technology standards where applicable. The service MUST employ the use of network and transport layer standards as defined by the Internet Engineering Task Force. The service MUST define one or more transport mechanisms for mandatory implementation.
</p>

<h4><a name="pred-stand-expr">3.1.3</a>&nbsp;Standard and Extensible Schemas</h4>

<p>
The service MUST define standard schemas for the exchange of data needed to implement the functionality in this document. In addition, there MUST be a means to allow the use of schemas not defined by the needs of this document. Both types of schemas MUST use the same schema language.
</p>

<h4><a name="level-access">3.1.4</a>&nbsp;Level of Access</h4>

<p>
The service MUST allow the classification of data as being either privileged or non-privileged, for the purpose of restricting access to privileged data. Note that this requirement makes no assumption or prescription as to what data (social or operational) might be considered privileged, but merely provides the ability to make the classification as necessary.
</p>

<p>
The service MUST be capable of serving both privileged and non-privileged data.
</p>

<p>
The service MUST be capable of authenticating privileged entities and ensuring that only those entities have access to both privileged and non-privileged data.
</p>

<p>
The service MUST be capable of providing access to non-privileged data without requiring authentication of any type (i.e. anonymous access).
</p>

<h4><a name="client-proc">3.1.5</a>&nbsp;Client Processing</h4>

<p>
The service MUST be capable of allowing machine parsable requests and responses.
</p>

<h4><a name="entity-ref">3.1.6</a>&nbsp;Entity Referencing</h4>

<p>
There MUST be a mechanism for an entity contained within a server to be referenced uniquely by an entry in another server.
</p>

<h4><a name="decentral">3.1.7</a>&nbsp;Decentralization</h4>

<p>
The service MUST be decentralized in design and principle and MUST NOT require the aggregation of data to a central repository, server, or entity. The service MAY allow for the optional aggregation of data indexes or hints. The service MUST NOT require aggregation of data indexes or hints.
</p>

<h4><a name="queyr-access">3.1.8</a>&nbsp;Query of Access Levels</h4>

<p>
If a query cannot yield a valid response due to insufficient permissions, the service MUST provide the client with an error response indicating this condition. The service SHOULD NOT provide a mechanism allowing a client to determine if a query will be denied before the query is submitted.
</p>

<p>
It is the intent of this requirement for clients to learn of inadequate permission status for a query only after the query has been submitted. Operating modes allowing a client to predetermine the queries that will or will not be denied are not encouraged for security considerations.
</p>

<h4><a name="domain-functions">3.2</a>&nbsp;Domain Specific Functions</h4>

<p>
These functions describe requirements specifically needed by <a href="#domain-registries">domain registries</a> and <a href="#domain-registrars">domain registrars</a>. Requirements specific to <a href="#other-registries">other registries</a> MUST be specified separately. No compliant service entity is required to support the functions required by every registry type.
</p>

<h4><a name="contact-lookup">3.2.1</a>&nbsp;Contact Lookup</h4>

<p>
The service MUST allow access to social data of contact entities given a unique reference to the contact entity.
</p>

<h4><a name="ns-lookup">3.2.2</a>&nbsp;Nameserver Lookup</h4>

<p>
The service MUST allow access to operational and social data of a nameserver given the fully-qualified host name or IP address of a nameserver.
</p>

<h4><a name="dom-stat-lookup">3.2.3</a>&nbsp;Domain Status Lookup</h4>

<p>
The service MUST provide access to the status of a domain given the domain's fully qualified name. This status MUST indicate the activation status of the domain. The activation status is the same as would be available in <a href="#dom-info-lookup">Domain Information Lookup</a>.
</p>

<h4><a name="dom-registrant-search">3.2.4</a>&nbsp;Domain Registrant Search</h4>

<p>
The service MUST provide the capability of searching for registrants by exact name match or a reasonable name subset. The service MAY provide limits to the number of results from this search to alleviate performance or comply with <a href="#mining-prev">Mining Prevention</a>. If the service limits the number of results from this search to alleviate performance, it MUST provide the client with a response indicating this condition. If the service limits the number of results from this search to comply with <a href="#mining-prev">Mining Prevention</a>, it MUST NOT provide the client with a response indicating this condition.
</p>

<p>
The service MUST provide a mechanism to distribute this search across all applicable domain registries and registrars. The service SHOULD have a means to narrow the scope of a search to a specific TLD. The service MUST be able to specify to the client an empty result set should the search yield no results.
</p>

<h4><a name="dom-info-lookup">3.2.5</a>&nbsp;Domain Information Lookup</h4>

<p>
The service MUST provide access to operational and social data specific to a domain given the domain's fully qualified name (FQDN). This information SHOULD include the following:
<ul class="text">

<li>
activation status
</li>

<li>
registrant name and contact data
</li>

<li>
hosting nameservers
</li>

<li>
technical, billing or other entity types associate with the domain and their relevant contact data, if any exist
</li>

<li>
the name of or a reference to the registry delegating the domain
</li>

<li>
the name of or a reference to the registrar for the domain, if one exists
</li>

</ul>

</p>

<h4><a name="ns-search">3.2.6</a>&nbsp;Nameserver Search</h4>

<p>
The service MAY allow the ability to list all domains hosted by a specific nameserver given the fully-qualified host name or IP address, if applicable, of the nameserver. The service MAY provide a mechanism to distribute this search across all applicable domain registries and registrars.
</p>

<h4><a name="escrow">3.2.7</a>&nbsp;Escrow Support</h4>

<p>
The service MUST provide a means to escrow data of domain registrars to an escrow entity using a common schema. This escrow capability SHOULD be "off-line" and "out-of-band" from the normal operations of the service.
</p>

<h4><a name="auth-dist">3.2.8</a>&nbsp;Authentication Distribution</h4>

<p>
The service MUST be capable of allowing a centralized authority entity the means to distribute authentication information of entities accessing the service. The service MUST not require all Internet registries to participate in distributed authentication and SHOULD allow the participation by an Internet registry in distributed authentication by many centralized authority entities.
</p>

<h4><a name="dom-name-search">3.2.9</a>&nbsp;Domain Name Search</h4>

<p>
The service MUST allow searching for domains by exact name match or a reasonable subset of a domain name. The service MAY provide limits to the number of results from this search to alleviate performance or comply with <a href="#mining-prev">Mining Prevention</a>. If the service limits the number of results from this search to alleviate performance, it MUST provide the client with a response indicating this condition. If the service limits the number of results from this search to comply with <a href="#mining-prev">Mining Prevention</a>, it MUST NOT provide the client with a response indicating this condition.
</p>

<p>
The service MUST provide a mechanism to distribute this search across all applicable domain registries and registrars. There should be a means to narrow this search based on a TLD. 
</p>

<p>
The search mechanism SHOULD provide for differences in domain names between the native representation and the canonical form existing in the registry.
</p>

<h4><a name="domain-dns-ref">3.2.10</a>&nbsp;DNS Label Referencing</h4>

<p>
The service MUST use <a href="#RFC1035">DNS</a>[2] to determine the authoritative source of information about domain names. It is the intention of this requirement that a client be able to determine via DNS and query the servers or set of servers of the domain registry delegating the domain name, the domain registrar responsible for registering the domain name if one is applicable, and the domain registrant of the domain name. The service SHOULD provide procedures or mechanisms to allow this determination if it cannot be done using DNS.
</p>

<h4><a name="dist-for-domain-types">3.2.11</a>&nbsp;Distribution for Domain Registry Types</h4>

<p>
The service MUST allow for the various registration distribution models of domain registry types described in <a href="#domain-registries">Domain Registries</a> while complying with <a href="#decentral">Decentralization</a>.
</p>

<a name="feature-requirements"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>4.&nbsp;Feature Requirements</h3>

<p>
Feature requirements describe the perceived need derived from the functional requirements for specific technical criteria of the directory service. This section makes references to terms and definitions declared in <a href="#glassory">Glossary</a> . This section uses the term "service" to denote the set of features to be provided by, and the expected behavior of, software built to meet these requirements in one or more protocols.
</p>

<p>
These requirements are for the purpose of designing a technical specification. The words used in this section are for compliance with <a href="#RFC2119">RFC2119</a>[8], do not reference or specify policy, and speak only to the capabilities in the derived technology.
</p>

<h4><a name="client-auth">4.1</a>&nbsp;Client Authentication</h4>

<p>
Entities accessing the service (users) MUST be provided a mechanism for passing credentials to a server for the purpose of authentication.
</p>

<h4><a name="referrals">4.2</a>&nbsp;Referrals</h4>

<p>
To distribute queries for search continuations and to issue entity references, the service MUST provide a referral mechanism.
</p>

<h4><a name="common-ref">4.3</a>&nbsp;Common Referral Mechanism</h4>

<p>
To distribute queries for search continuation and to issue entity references, the service MUST define a common referral scheme and syntax.
</p>

<h4><a name="structure">4.4</a>&nbsp;Structured Queries and Responses</h4>

<p>
To provide for machine consumption as well as human consumption, the service MUST employ structured queries and responses.
</p>

<h4><a name="existing-schema">4.5</a>&nbsp;Existing Schema Language</h4>

<p>
To provide structured queries and responses and allow for minimal technological reinvention, the service MUST employ a pre-existing schema language.
</p>

<h4><a name="defined-schemas">4.6</a>&nbsp;Defined Schemas</h4>

<p>
To provide for machine consumption as well as human consumption, the service MUST define schemas for use by the structured queries and responses.
</p>

<h4><a name="serialization">4.7</a>&nbsp;Serialization Definition</h4>

<p>
To provide for data escrow and allow for minimal technological reinvention, the service MUST employ a pre-existing serialization specification.
</p>

<a name="internationalization-con"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>5.&nbsp;Internationalization Considerations</h3>

<p>
Requirements defined in this document MUST consider the best practices spelled out in <a href="#RFC2277">[6]</a>.
</p>

<a name="iana-con"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>6.&nbsp;IANA Considerations</h3>

<p>
IANA consideration for any service meeting these requirements will depend upon the technologies chosen and MUST be specified by any document describing such a service.
</p>

<a name="security-con"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>7.&nbsp;Security Considerations</h3>

<p>
This document contains requirements for the validation of authenticated entities and the access of authenticated entities compared with the access of non-authenticated entities. This document does not define the mechanism for validation of authenticated entities. Requirements defined in this document MUST allow for the implementation of this mechanism according best common practices.
</p>

<p>
The requirement in <a href="#level-access">Level of Access</a> must be weighed against other requirements specifying search or lookup capabilities.
</p>

<p>
In addition, this document contains requirements for referrals and entity references. Client implementations based on these requirements SHOULD take proper care in the safe-guarding of credential information when resolving referrals or entity references according to best common practices.
</p>
<a name="rfc.references"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>
References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><b><a name="RFC2251">[1]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Wahl, M.</a>, <a href="mailto:[email-masked]">Howes, T.</a> and <a href="mailto:[email-masked]">S. Kille</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2251.txt">Lightweight Directory Access Protocol (v3)</a>", RFC 2251, December 1997.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC1035">[2]</a></b></td>
<td class="author-text"><a href="mailto:">Mockapetris, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain names - implementation and specification</a>", STD 13, RFC 1035, November 1987.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2167">[3]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Williamson, S.</a>, <a href="mailto:[email-masked]">Kosters, M.</a>, <a href="mailto:[email-masked]">Blacka, D.</a>, <a href="mailto:[email-masked]">Singh, J.</a> and <a href="mailto:[email-masked]">K. Zeilstra</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2167.txt">Referral Whois (RWhois) Protocol V1.5</a>", RFC 2167, June 1997.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC0954">[4]</a></b></td>
<td class="author-text">Harrenstien, K., Stahl, M. and E. Feinler, "<a href="ftp://ftp.isi.edu/in-notes/rfc954.txt">NICNAME/WHOIS</a>", RFC 954, October 1985.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2622">[5]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Alaettinoglu, C.</a>, <a href="mailto:[email-masked]">Villamizar, C.</a>, <a href="mailto:[email-masked]">Gerich, E.</a>, <a href="mailto:[email-masked]">Kessens, D.</a>, <a href="mailto:[email-masked]">Meyer, D.</a>, <a href="mailto:[email-masked]">Bates, T.</a>, <a href="mailto:[email-masked]">Karrenberg, D.</a> and <a href="mailto:[email-masked]">M. Terpstra</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2622.txt">Routing Policy Specification Language (RPSL)</a>", RFC 2622, June 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2277">[6]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Alvestrand, H.T.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2277.txt">IETF Policy on Character Sets and Languages</a>", BCP 18, RFC 2277, January 1998.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2535">[7]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2535.txt">Domain Name System Security Extensions</a>", RFC 2535, March 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2119">[8]</a></b></td>
<td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td></tr>
</table>

<a name="rfc.authors"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Andrew L. Newton</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">VeriSign, Inc.</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">21345 Ridgetop Circle</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Sterling, VA  20166</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Phone:&nbsp;</td>
<td class="author-text">+1 703 948 3382</td></tr>
<tr><td class="author" align="right">EMail:&nbsp;</td>
<td class="author-text"><a href="mailto:[email-masked]">[email-masked]</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://www.verisignlabs.com/">http://www.verisignlabs.com/</a></td></tr>
</table>

<a name="glassory"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix A.&nbsp;Glossary</h3>

<p>

<ul class="text">

<li>
TLD: Initials for "top level domain." Referes to domains in <a href="#RFC1035">DNS</a>[2]that are hierarchically at the level just beneath the root.
</li>

<li>
ccTLD: Initials for "country code top level domain." TLD's which use one of the two character country codes defined by ISO.
</li>

<li>
gTLD: Initials for "generic top level domain." TLD's that do not use one of the two character country codes defined by ISO.
</li>

<li>
social data: Data containing names and contact information (i.e. postal addresses, phone numbers, e-mail addresses) of humans or legal entities.
</li>

<li>
operational data: Data necessary to the operation of networks and network related services and items.
</li>

<li>
RIR: Initials for "regional Internet registry."
</li>

<li>
IRR: Initials for "Internet routing registry."
</li>

<li>
authenticated entity: A person, or person acting on behalf of an organization, who has provided validatable credentials of identification via client software to the directory service of an Internet registry.
</li>

<li>
non-authenticated entity: A person, or person acting on behalf of an organization, who has not provided validatable credentials of identification via client software to the directory service of an Internet registry.
</li>

<li>
privileged entity: A person, or person acting on behalf of an organization, with authorization to access data.
</li>

<li>
non-privileged entity: A person, or person acting on behalf on an organization, with no authorization to access data.
</li>

<li>
privileged data: Data accessible by a privileged entities.
</li>

<li>
non-privileged data: Data accessible by privileged entities and non-privileged entities.
</li>

<li>
forward lookup: a DNS lookup where a domain name is resolved to an IP address.
</li>

<li>
reverse lookup: a DNS lookup where an IP address is resolved to a domain name.
</li>

<li>
mining: In the context of this document, this term is specific to data mining. This is a methodical process to obtain the contents of directory service, usually as much as possible, not relevant to any immediate need. Data mining is often not a practice welcomed by registry operators.
</li>

</ul>

</p>

<a name="acknowledgements"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix B.&nbsp;Acknowledgements</h3>

<h4><a name="forums">B.1</a>&nbsp;Forums</h4>

<p>
The proceedings of the following public forums were used as input to the scope and requirements for this document: 
<ul class="text">

<li>
<a href="http://www.ietf.org/proceedings/00dec/00dec-41.htm">whois BOF of the 49th IETF</a>; December 10-15, 2000; San Diego, CA, USA
</li>

<li>
<a href="http://www.ietf.org/proceedings/01aug/51-40.htm">whoisfix BOF of the 51st IETF</a>; August 5-10, 2001; London, England
</li>

<li>
<a href="http://www.uwho.verisignlabs.com/Final-WhoIsPanel-Aug15-Resume.pdf">First UWho Consultation</a>; August 15, 2001; Washington, DC, USA
</li>

<li>
Second UWho Consultation; November 15, 2001; Marina del Rey, CA, USA
</li>

<li>
Third UWho Consultation; November 19, 2001; Washington, DC, USA
</li>

<li>
DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic
</li>

<li>
<a href="http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/min_database.html">Database WG of RIPE 40</a>; October 1-5, 2001; Praque, Czech Republic
</li>

<li>
<a href="http://www.nanog.org/mtg-0110/lookup.html">General Session of NANOG 23</a>; October 21-23; Oakland, CA, USA
</li>

<li>
DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
</li>

<li>
Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
</li>

<li>
NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
</li>

<li>
CENTR General Assembly, February 21-22, 2002; Rambouillet, France
</li>

<li>
CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis, Minnesota, USA
</li>

</ul>

</p>

<h4><a name="working-group">B.2</a>&nbsp;Working Group</h4>

<p>
This document is a work item of the Cross-Registry Internet Service Protocol (CRISP) Working Group in the Applications Area of the IETF. Discussions for this working group are held on the email list [email-masked]. To subscribe to this email list, send email to [email-masked] with a subject line of "subscribe". Archives of this list may be found out http://lists.verisignlabs.com/pipermail/ietf-not43/.
</p>

<h4><a name="contributions">B.3</a>&nbsp;Contributions</h4>

<p>
Comments, suggestions, and feedback of significant substance have been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr, and Cathy Murphy.
</p>
<a name="rfc.copyright"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Full Copyright Statement</h3>
<p class='copyright'>
Copyright (C) The Internet Society (2002). All Rights Reserved.</p>
<p class='copyright'>
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.</p>
<p class='copyright'>
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.</p>
<p class='copyright'>
This document and the information contained herein is provided on an
&quot;AS IS&quot; 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.</p>
<h3>Acknowledgement</h3>
<p class='copyright'>
Funding for the RFC editor function is currently provided by the
Internet Society.</p>
</font></body></html>

--------------10D531E406820549FCF3A484--

---

From: [email-masked] (Leslie Daigle)
Date: Mon, 05 Aug 2002 14:00:40 -0400

Howdy,

Some questions & comments -- in-line:

>    client with a response indicating this condition.

s/alleviate/improve/ or s/performance/performance bottlenecks/ 

WRT the actual requirements -- I'm not sure I understand the motivation
for when the service MUST or MUST NOT provide an indication
that it has truncated the reply.  In particular, I'm not sure I
agree that it's valuable for the service to fail silently when
something that is perceived to be data mining occurs.  It may
have been a badly-formed query, not a deliberate attempt to
mine.  Clients that submit badly-formed queries ought to be given
the indication that they didn't get the full result set & therefore
ought to reconsider the query.  Shouldn't they?

>    3.1.1, it MUST NOT provide the client with a response indicating

Same comments as above.

>    between the native representation and the canonical form existing

I don't think this is clear.  I believe this is speaking to the
fact that domain names will be registered using a 7-bit form (nameprep),
and the theory is to allow/require the service to store a different
representation (e.g., particular character set, encoding) of the
registered "name", as well as the name of the encoding + algorithm used
to transform it into UTF-8 before nameprep.

I think this last sentence is missing something; determine _what_
and query the servers?

>    allow this determination if it cannot be done using DNS.

I have probably missed a step, but I don't understand why the
service SHOULD do this, if it MUST provide the DNS route -- or
is the point that it should have a backup plan in case there are
transient or configuration errors with DNS at the moment a query is
made?

Leslie.

-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
       -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: [email-masked] (Andrew Newton)
Date: Mon, 05 Aug 2002 14:38:16 -0400

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zark-19274-1028573289-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Some questions & comments -- in-line:

ditto.

> s/alleviate/improve/ or s/performance/performance bottlenecks/

Works for me.

> ought to reconsider the query.  Shouldn't they?

If the service truncates the results for performance reasons, you can an
indication of this condition.

If the service truncates the results because it believes you are data
mining, you get no indication of this condition.  This makes it more
difficult, though not impossible, to determine if all the results have
been returned.

> to transform it into UTF-8 before nameprep.

You are correct, it isn't clear.  That text seems to acknowledge this as
an issue and at the same time defer any decision on what to do for some
other time or place.

I think we as a working group need to decide what will be done with
internationalized domain names.  Unlike the IDN folks, we do have the
advantage of having a NEW protocol that can have things like fields
indicating language and so forth.  Suggestions?

> transient or configuration errors with DNS at the moment a query is

Though transient or configuration errors are also good reasons, I was
mostly thinking that some delegation points will never have this type of
information in DNS in things like SRV records (obviously in NS records).

-andy
--=_zark-19274-1028573289-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_zark-19274-1028573289-0001-2--

---

From: [email-masked] (Leslie Daigle)
Date: Mon, 05 Aug 2002 15:58:19 -0400

On the specific point of whether the service MUST NOT return
an error response indicating that the result list was truncated,
I think it would be useful to hear more from the WG as to which
is most important, or how can we reconcile:

	. mining prevention.  If no error message is given, the
	  hypothesis is that a mining client will not attempt to
	  revise the query to pick up where the results left off
	  (i.e., if a query was for "AAA*", and the results 
	  included "AAAA" through "AAAM", query for "AAAN*")

	. accurate responses to legitimate queries.  If no error
	  message is given, a legitimate queryant will not
	  know that they have in fact missed data and should re-frame
	  their query in a more precise fashion (i.e., if they
	  asked for "AAA*", and got a truncated response, they
	  should specify more, e.g., "AAARDVAR*").

Although I respect the mining prevention requirement, I'm not
personally pleased with silent failure.  I think the examples
I've given above are pretty trivial -- it's less obvious if
multiple criteria are involved (and at this instant, I don't
recall if we have requirements to support such).  

Leslie.

-- 

Leslie Daigle
[email-masked]

---

From: [email-masked] (Eric A. Hall)
Date: Mon, 05 Aug 2002 15:50:39 -0500

> indicating language and so forth.  Suggestions?

There are several different issues here. Are we talking about the resource
being queried for, the servers being queried, or both? With LDAP-WHOIS in
particular, there is the DIT domain (dc=label) plus the query string
(cn=domain). UTF-8 can be used wherever we want but if we use it for the
DIT parts then that affects the LDAP domainComponent matching syntax,
which is arguably out of scope. At the same time, having part of the
string be ASCII-compatible encoding (ACE) and another part be UTF-8 is
somewhat clumsy and dare-I-say error-prone.

Another related issue, are we talking about the UI or the protocol? Saying
that the input sequence should be converted before the query string is
built would make some sense as a minimalist approach.

On the other hand, do we want to mandate that all DITs *MUST* use the ACE
form in their directory trees? Who wants to look at ACE gobbledygoop in
their DIT, or worse be required to do it?

And so forth. Ugly stuff.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Andrew Newton)
Date: Mon, 05 Aug 2002 17:07:02 -0400

--=_zark-20634-1028582218-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Eric A. Hall" wrote:
> being queried for, the servers being queried, or both? 

I was assuming the resource which is being queried.  If we have to make
special arrangements for the servers being queried, then perhaps the IDN
WG has missed the mark.

> With LDAP-WHOIS in

I agree.

> their DIT, or worse be required to do it?

I'm not sure which, as I'm not an expert in this internationalization
stuff.  My gut tells me that it could be done in the UI as you
suggested.  However, how does that work with partial-name searches?

> And so forth. Ugly stuff.

Again, agreed!

-andy
--=_zark-20634-1028582218-0001-2

--=_zark-20634-1028582218-0001-2--

---

From: [email-masked] (Andrew Newton)
Date: Mon, 05 Aug 2002 17:12:56 -0400

--=_zark-20709-1028582569-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

After thinking about this some more, it has occured to me that perhaps
the wording for this section has actually crossed the line from "what
can be done" to "what must be done", despite our best intentions to
avoid stating policy.  Therefore, it must be reworked.

I think the right thing to do would be to stipulate that the protocols
have such a feature to notify the user of the truncation condition.  The
use of these notifications are, and in reality will be, site specific.

-andy

> recall if we have requirements to support such).
--=_zark-20709-1028582569-0001-2

--=_zark-20709-1028582569-0001-2--

---

From: [email-masked] (Eric A. Hall)
Date: Mon, 05 Aug 2002 18:45:22 -0500

on 8/5/2002 4:07 PM Andrew Newton wrote:
> "Eric A. Hall" wrote:
>
>> There are several different issues here. Are we talking about the
>> resource being queried for, the servers being queried, or both?
>
>  special arrangements for the servers being queried, then perhaps the
> IDN WG has missed the mark.

I was speaking in the logical. In the case of LDAP-WHOIS, the DIT is used
to determine the servers. Unless there are rules which state how DITs are
to be mapped, there is significant potential for error. I think that these
rules are out of scope for us, unfortunately.

I'll look at the LDAP URL in depth at some point and figure out what our
options are. At the moment, I am pretty certain that all referenced domain
names will have to be ACE. This is unfortunate, since it means that the
DITs and the entries will also have to be ACE.

As to whether or not the IDN WG succeeded or not, keep in mind that the
only extra-IETF pressures were on the resell side. Thus, the IDN only
really had to devise a consistent encoding format so that everybody was
selling the same domain names, not so that users could actually use them.
Unfortunate but there you have it.

> suggested.  However, how does that work with partial-name searches?

No

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Tue, 6 Aug 2002 08:49:57 +0200

On Mon, Aug 05, 2002 at 05:07:02PM -0400,
 Andrew Newton <[email-masked]> wrote 

> > somewhat clumsy and dare-I-say error-prone.

I'm not sure we will have the choice. For the domain names, we have to
stick with IDNA and ACE. For the social information (names and addresses
of the contacts, for instance), unless we want to force them to go
through nameprep + ACE, we will use Unicode. So, even in the
registry's database, we will have the problem.

The only other solutions I see are:

1) storing the original (Unicode) form of the domain name as well as
the ACE. It requires a change in the registrar-registry protocol
(draft-ietf-provreg-epp-domain-04.txt contains nothing about
transmitting the original form).

2) As I said before, using nameprep + ACE with contact information. I
would disagree. ACE was choosen for specific reasons (the ability to
use existing nameserver sofwtare), we should not push that hack too
far.

> suggested.

For the domain names, it seems the only reasonable choice, and
consistent with IDNA.

>  However, how does that work with partial-name searches?

As soon as you move from US-ASCII, "fuzzy" searches (including
partial-name but also accent-insensitive searches, etc) become very
difficult to specify because each language has its own rules.

If we want to stay away from registry policy, I suggest to accept
solution 1 ("the registry MAY store the original form of the IDN and
MAY accept queries based on the original form") but not to mandate it.

---

From: [email-masked] (Patrick)
Date: Tue, 6 Aug 2002 12:39:20 +0200

> stick with IDNA and ACE. For the social information (names and addresses

I disagree. IDNA & ACE are used instead of UTF-8 to be able to have
iDNS right now, that is without changing all software (name servers,
resolvers library, etc...)
For a new protocol, I see no reason to use ACE.

> transmitting the original form).

Based on XML, EPP is already using UTF-8.
It includes specific details about internationalized strings in
contact details (they do not need to use ACE at all, hopefully).

I do not think this requires any change.
I quote:
2.1 Domain and Host Names   
  The syntax for domain and host names described in this document
  MUST  conform to [RFC952] as updated by [RFC1123].  These
  conformance requirements might change as a result of progressing
  work in developing standards for internationalized domain names.

I suppose that registries could accept through EPP domain names in
UTF-8 and do the ACE thing themselves... until the time ACE is not
needed anymore.

> use existing nameserver sofwtare), we should not push that hack too

So, we agree on that and we should extend that idea to domain names.

Patrick.

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Tue, 6 Aug 2002 13:57:04 +0200

On Tue, Aug 06, 2002 at 12:39:20PM +0200,
 Patrick <[email-masked]> wrote 

> So, we agree on that and we should extend that idea to domain names.

So, to summary:

The Registry should accept Unicode in domain names (and contact
information), using plain EPP (It can reduce the set of acceptable
characters in its policy, for instance, .eu could restrict itself to
Latin-1 and Greek.)

The Registry translates to ACE just to check the unicity and to
generate the zone files.

Since the Registry's database stores Unicode, information protocols
like IRIS can use it natively (thus solving the partial-name matching
problem but of course not all the funny other matching problems of
Unicode).

Implementation note: I'm not sure that all EPP servers authors are
aware of that and react gracefully to IDN. A note in the future RFC
could be useful.

---

From: [email-masked] (Patrick)
Date: Tue, 6 Aug 2002 17:36:52 +0200

> problem but of course not all the funny other matching problems of

Sounds good to me ;-)
And when all software will be updated, the ACE part will vanish.
Hopefully ;-)

> aware of that and react gracefully to IDN. A note in the future RFC

See the paragraph quoted previously : EPP is built on current RFC
regarding what you put in domain names (for now A-Z 0-9 and -), but
clearly specifies future directions to be in accordance with new RFCs
(that is after IDN WG produces them), and is built with XML which is
already happy with UTF-8.
Current implementations may not support it, but it is just a matter
of upgrading them when the time arrives ;-)
(FYI our toolkit soon to be released implementing EPP does not
support characters outside what described above for domain names, and
we will update it when IDN registrations become something really
existing)

Patrick.

---

From: [email-masked] (Andrew Newton)
Date: Tue, 06 Aug 2002 11:59:48 -0400

--=_zark-25379-1028650186-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> problem but of course not all the funny other matching problems of

After reading this and the discussion Stephane brought up on the PROVREG
list, this seems reasonable to me.

However, this still leaves open the issues Eric mentioned... what
encoding to you use for the DNS label when finding the authoritative
server, and what do you do with URL's?

-andy
--=_zark-25379-1028650186-0001-2

--=_zark-25379-1028650186-0001-2--

---

From: [email-masked] (Ted Hardie)
Date: Tue, 6 Aug 2002 10:04:06 -0700 (PDT)

> use of these notifications are, and in reality will be, site specific.

This gets to be hard to debug; if I might or might not get a specific
error based on which service provider I'm talking to, we can end up
back in the soup pretty quickly.  I'd rather see the requirement say
something like:

"The service MUST indicate if a response has been truncated using
a standard error mechanism, but MAY omit details from that response
in order to hinder the 'chaining' of requests by data miners".

This does err on the side of supporting standard errors over 
avoiding data mining, but I'd really, really hate for us to be
back in the situation where diagnostics have to be cased for individual
services.
			regards,
				Ted Hardie

---

From: [email-masked] (Leslie Daigle)
Date: Tue, 06 Aug 2002 13:26:35 -0400

I'd prefer this -- I always like deterministic behaviour :-) 
But I think I agree with Andy in that it's not what will get 
implemented, irrespective of what our requirements state.

So, two possibilities:

	. as proposed below:  will servers in fact implement
	  sufficiently random deletions from the result set,
	  or will miners simply try to chain, anyway.

	. as currently written in the requirements doc:  the service 
	  MUST fail silently when it has a query that generates too 
	  many hits.  Both legitimate clients and miners will have
	  to retry queries to confirm they got everything they
	  wanted...

At this point, it seems like we're trying to do behaviour modification
on end-users via requirements for a service that will be implemented
in some as-yet-to-be-decided protocol... that seems like too many
layers of indirection for sanity.

Leslie.

-- 

Leslie Daigle
[email-masked]

---

From: [email-masked] (Ted Hardie)
Date: Tue, 6 Aug 2002 10:58:35 -0700 (PDT)

> layers of indirection for sanity.

Leslie,
	I'm not sure that we are trying to do behavior mod on the end
user; I think we're trying to do protocol design based on the abusive
cases rather than normal use.  Given the strong message we've received
that data mining is a problem, I think we do have to take it into
account, but not to the point where we seriously perturb the behavior
of the protocol.
	I advocate changing the current "silent failure" requirement.
I believe it hinders normal use, and does not stop abusive behavior.
I'd like to change it to something that supports normal use in an
interoperable and deterministic way.  I'm totally open to suggestions
as to what that might be, if the error message with omitted details
is not appropriate.
			regards,
					Ted Hardie

---

From: [email-masked] (Andrew Newton)
Date: Tue, 06 Aug 2002 14:39:20 -0400

--=_zark-26325-1028659759-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> as to what that might be, if the error message with omitted details

Ted,

I still think my point is valid.  We can stipulate that the protocol
provide such an indicator, but its use will really be up to the
individual operators.  There really is no way to mandate it other than
to go to every registry operator and demand to see their list of
domains.

-andy
--=_zark-26325-1028659759-0001-2

--=_zark-26325-1028659759-0001-2--

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Wed, 7 Aug 2002 15:46:07 +0200

On Tue, Aug 06, 2002 at 05:36:52PM +0200,
 Patrick <[email-masked]> wrote 

> already happy with UTF-8.

It is not only an issue with IDN. The LibertyRMS test bed does not
allow contact information in Unicode either ("syntax error"). And I
assume most (all?)  EPP servers will do the same.

> of upgrading them when the time arrives ;-)

Let's cross our fingers. I'm not really optimistic.

---

From: [email-masked] (Patrick)
Date: Wed, 7 Aug 2002 16:04:06 +0200

> assume most (all?)  EPP servers will do the same.

Again, maybe I was not clear :
the libertyRMS test best (or any other) is not authoritative at all.
The fact that it today does not do something that may or should be
done in the future is no indication at all there is a problem...
except the fact that the software will need to be updated in the
future.

BTW some EPP Registries works without problems with Unicode caracters
in contact. Our own toolkit handles that without problems.

> Let's cross our fingers. I'm not really optimistic.

I do not understand. When Registries will need to do true Unicode
domain names they will update their software, that is all.

And besides, I will dare to say that it would be a small update.

Patrick.