ICANN/DNSO
DNSO Mailling lists archives

[nc-transfer]


<<< Chronological Index >>>    <<< Thread Index >>>

[nc-transfer] FW: draft-ietf-crisp-requirements-00.txt.1

  • To: "Transfer TF (E-mail)" <nc-transfer@dnso.org>
  • Subject: [nc-transfer] FW: draft-ietf-crisp-requirements-00.txt.1
  • From: "Cade,Marilyn S - LGA" <mcade@att.com>
  • Date: Tue, 24 Sep 2002 17:47:49 -0400
  • Cc: "Rick Wesson (E-mail)" <wessorh@ar.com>
  • Sender: owner-nc-transfer@dnso.org
  • Thread-Index: AcJj4FoxAoRoRLDySl+KJMyZCVidgQAM6kbA
  • Thread-Topic: draft-ietf-crisp-requirements-00.txt.1

Title: FW: draft-ietf-crisp-requirements-00.txt.1

Thanks, Abel, for the reminder. I meant to forward to the TF earlier. Aplogies, and thanks to Rick.

-----Original Message-----
From: Rick Wesson [mailto:wessorh@ar.com]
Sent: Tuesday, September 24, 2002 11:38 AM
To: Cade,Marilyn S - LGA
Subject: draft-ietf-crisp-requirements-00.txt.1



the crisp requirements are attached.

-rick


Network Working Group                                          A. Newton
Internet-Draft                                            VeriSign, Inc.
Expires: January 29, 2003                                  July 31, 2002


     Cross Registry Internet Service Protocol (CRISP) Requirements
                    draft-ietf-crisp-requirements-00

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 January 29, 2003.

Copyright Notice

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

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.










Newton                  Expires January 29, 2003                [Page 1]

Internet-Draft             crisp-requirements                  July 2002


Table of Contents

   1.     Background . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.     Internet Registry Communities  . . . . . . . . . . . . . .   5
   2.1    Domain Name System Registries  . . . . . . . . . . . . . .   5
   2.1.1  Domain Registries  . . . . . . . . . . . . . . . . . . . .   5
   2.1.2  Domain Registrars  . . . . . . . . . . . . . . . . . . . .   5
   2.2    Other Registries . . . . . . . . . . . . . . . . . . . . .   6
   2.2.1  Regional Internet Registries . . . . . . . . . . . . . . .   6
   2.2.2  Local Internet Registries  . . . . . . . . . . . . . . . .   6
   2.2.3  Internet Routing Registries  . . . . . . . . . . . . . . .   6
   2.2.4  Incident Coordination Contact Registries . . . . . . . . .   6
   2.2.5  Network Edge Resource Registries . . . . . . . . . . . . .   7
   2.3    Implementers . . . . . . . . . . . . . . . . . . . . . . .   7
   2.4    End Users  . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.4.1  Service Providers and Network Operators  . . . . . . . . .   7
   2.4.2  Intellectual Property Holders  . . . . . . . . . . . . . .   7
   2.4.3  Law Enforcement  . . . . . . . . . . . . . . . . . . . . .   7
   2.4.4  Certificate Authorities  . . . . . . . . . . . . . . . . .   8
   2.4.5  DNS Users  . . . . . . . . . . . . . . . . . . . . . . . .   8
   2.4.6  Domain Registrants . . . . . . . . . . . . . . . . . . . .   8
   2.5    Other Actors . . . . . . . . . . . . . . . . . . . . . . .   8
   3.     Functional Requirements  . . . . . . . . . . . . . . . . .   9
   3.1    Base Functions . . . . . . . . . . . . . . . . . . . . . .   9
   3.1.1  Mining Prevention  . . . . . . . . . . . . . . . . . . . .   9
   3.1.2  Minimal Technical Reinvention  . . . . . . . . . . . . . .   9
   3.1.3  Standard and Extensible Schemas  . . . . . . . . . . . . .   9
   3.1.4  Level of Access  . . . . . . . . . . . . . . . . . . . . .  10
   3.1.5  Client Processing  . . . . . . . . . . . . . . . . . . . .  10
   3.1.6  Entity Referencing . . . . . . . . . . . . . . . . . . . .  10
   3.1.7  Decentralization . . . . . . . . . . . . . . . . . . . . .  10
   3.1.8  Query of Access Levels . . . . . . . . . . . . . . . . . .  10
   3.2    Domain Specific Functions  . . . . . . . . . . . . . . . .  11
   3.2.1  Contact Lookup . . . . . . . . . . . . . . . . . . . . . .  11
   3.2.2  Nameserver Lookup  . . . . . . . . . . . . . . . . . . . .  11
   3.2.3  Domain Status Lookup . . . . . . . . . . . . . . . . . . .  11
   3.2.4  Domain Registrant Search . . . . . . . . . . . . . . . . .  11
   3.2.5  Domain Information Lookup  . . . . . . . . . . . . . . . .  12
   3.2.6  Nameserver Search  . . . . . . . . . . . . . . . . . . . .  12
   3.2.7  Escrow Support . . . . . . . . . . . . . . . . . . . . . .  12
   3.2.8  Authentication Distribution  . . . . . . . . . . . . . . .  12
   3.2.9  Domain Name Search . . . . . . . . . . . . . . . . . . . .  13
   3.2.10 DNS Label Referencing  . . . . . . . . . . . . . . . . . .  13
   3.2.11 Distribution for Domain Registry Types . . . . . . . . . .  13
   4.     Feature Requirements . . . . . . . . . . . . . . . . . . .  14
   4.1    Client Authentication  . . . . . . . . . . . . . . . . . .  14
   4.2    Referrals  . . . . . . . . . . . . . . . . . . . . . . . .  14
   4.3    Common Referral Mechanism  . . . . . . . . . . . . . . . .  14
   4.4    Structured Queries and Responses . . . . . . . . . . . . .  14


Newton                  Expires January 29, 2003                [Page 2]

Internet-Draft             crisp-requirements                  July 2002


   4.5    Existing Schema Language . . . . . . . . . . . . . . . . .  14
   4.6    Defined Schemas  . . . . . . . . . . . . . . . . . . . . .  14
   4.7    Serialization Definition . . . . . . . . . . . . . . . . .  15
   5.     Internationalization Considerations  . . . . . . . . . . .  16
   6.     IANA Considerations  . . . . . . . . . . . . . . . . . . .  17
   7.     Security Considerations  . . . . . . . . . . . . . . . . .  18
          References . . . . . . . . . . . . . . . . . . . . . . . .  19
          Author's Address . . . . . . . . . . . . . . . . . . . . .  19
   A.     Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  20
   B.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  22
   B.1    Forums . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   B.2    Working Group  . . . . . . . . . . . . . . . . . . . . . .  22
   B.3    Contributions  . . . . . . . . . . . . . . . . . . . . . .  23
          Full Copyright Statement . . . . . . . . . . . . . . . . .  24





































Newton                  Expires January 29, 2003                [Page 3]

Internet-Draft             crisp-requirements                  July 2002


1. Background

   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 whois[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 rwhois[3], to fulfill other
   needs, and proposals for the use of other technologies such as
   LDAP[1] and XML.

   The scope of the requirements captured in this document relate to
   the directory services of Internet registries and their related
   communities (Section 2.3,Section 2.4, and Section 2.5). This scoping
   specifically targets the requirements of domain name registries
   (Section 2.1) while acknowledging extensibility needs for possible
   future support of the requirements for other registry (Section 2.2)
   types. The requirements are of both the current use of these
   directory services and the desired functionality based on input from
   relevant forums (Appendix B.1). These requirements are not specific
   to any protocol. Terms used in the definition of requirements in
   this document may be found in the glossary (Appendix A).

   The requirements captured in this document are for the purpose of
   designing technical specifications. The words used in this document
   for compliance with RFC2119[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.
















Newton                  Expires January 29, 2003                [Page 4]

Internet-Draft             crisp-requirements                  July 2002


2. Internet Registry Communities

   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.

2.1 Domain Name System Registries

2.1.1 Domain Registries

   Domain registries are responsible for the registration of domains
   for use with DNS[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.

   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.

   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 social data
   (Appendix 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.

   Domain registries not described in this section (Section 2.1.1) are
   not the subject of this document and may have requirements that are
   out of scope for this subject matter.

2.1.2 Domain Registrars

   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


Newton                  Expires January 29, 2003                [Page 5]

Internet-Draft             crisp-requirements                  July 2002


   domain on behalf of a registrant in more than one domain registry.

2.2 Other Registries

2.2.1 Regional Internet Registries

   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. 

2.2.2 Local Internet Registries

   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.

2.2.3 Internet Routing Registries

   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 RPSL[5]. 

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

   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. 

2.2.4 Incident Coordination Contact Registries

   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.



Newton                  Expires January 29, 2003                [Page 6]

Internet-Draft             crisp-requirements                  July 2002


2.2.5 Network Edge Resource Registries

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

2.3 Implementers

   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.

2.4 End Users

2.4.1 Service Providers and Network Operators

   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.

2.4.2 Intellectual Property Holders

   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.

2.4.3 Law Enforcement

   Law enforcement agencies use the directory services of Internet
   registries to find information used to carry out the enforcement of


Newton                  Expires January 29, 2003                [Page 7]

Internet-Draft             crisp-requirements                  July 2002


   laws within their jurisdictions.

2.4.4 Certificate Authorities

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

2.4.5 DNS Users

   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.

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.

2.5 Other Actors

   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.























Newton                  Expires January 29, 2003                [Page 8]

Internet-Draft             crisp-requirements                  July 2002


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 Base Functions

   This section describes basic service requirements for an Internet
   registry service for any of the registries (domain name registries
   (Section 2.1) and other registries (Section 2.2)). Additional
   requirements, specific to domain registries, are described in Domain
   Specific Functions (Section 3.2).

3.1.1 Mining Prevention

   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.

3.1.2 Minimal Technical Reinvention

   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.

3.1.3 Standard and Extensible Schemas

   The service MUST define standard schemas for the exchange of data


Newton                  Expires January 29, 2003                [Page 9]

Internet-Draft             crisp-requirements                  July 2002


   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.

3.1.4 Level of Access

   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.

   The service MUST be capable of serving both privileged and
   non-privileged data.

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

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

3.1.5 Client Processing

   The service MUST be capable of allowing machine parsable requests
   and responses.

3.1.6 Entity Referencing

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

3.1.7 Decentralization

   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.

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


Newton                  Expires January 29, 2003               [Page 10]

Internet-Draft             crisp-requirements                  July 2002


   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 Domain Specific Functions

   These functions describe requirements specifically needed by domain
   registries (Section 2.1.1) and domain registrars (Section 2.1.2).
   Requirements specific to other registries (Section 2.2) MUST be
   specified separately. No compliant service entity is required to
   support the functions required by every registry type.

3.2.1 Contact Lookup

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

3.2.2 Nameserver Lookup

   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.

3.2.3 Domain Status Lookup

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

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


Newton                  Expires January 29, 2003               [Page 11]

Internet-Draft             crisp-requirements                  July 2002


   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.6 Nameserver Search

   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.

3.2.7 Escrow Support

   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.

3.2.8 Authentication Distribution

   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.





Newton                  Expires January 29, 2003               [Page 12]

Internet-Draft             crisp-requirements                  July 2002


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.















Newton                  Expires January 29, 2003               [Page 13]

Internet-Draft             crisp-requirements                  July 2002


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.

4.1 Client Authentication

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

4.2 Referrals

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

4.3 Common Referral Mechanism

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

4.4 Structured Queries and Responses

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

4.5 Existing Schema Language

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

4.6 Defined Schemas

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



Newton                  Expires January 29, 2003               [Page 14]

Internet-Draft             crisp-requirements                  July 2002


4.7 Serialization Definition

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














































Newton                  Expires January 29, 2003               [Page 15]

Internet-Draft             crisp-requirements                  July 2002


5. Internationalization Considerations

   Requirements defined in this document MUST consider the best
   practices spelled out in [6].















































Newton                  Expires January 29, 2003               [Page 16]

Internet-Draft             crisp-requirements                  July 2002


6. IANA Considerations

   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.














































Newton                  Expires January 29, 2003               [Page 17]

Internet-Draft             crisp-requirements                  July 2002


7. Security Considerations

   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.

   The requirement in Section 3.1.4 must be weighed against other
   requirements specifying search or lookup capabilities.

   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.

































Newton                  Expires January 29, 2003               [Page 18]

Internet-Draft             crisp-requirements                  July 2002


References

   [1]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol (v3)", RFC 2251, December 1997.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
        Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
        June 1997.

   [4]  Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
        954, October 1985.

   [5]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
        Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
        Policy Specification Language (RPSL)", RFC 2622, June 1999.

   [6]  Alvestrand, H.T., "IETF Policy on Character Sets and
        Languages", BCP 18, RFC 2277, January 1998.

   [7]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [8]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [9]   <http://www.ietf.org/proceedings/00dec/00dec-41.htm>

   [10]  <http://www.ietf.org/proceedings/01aug/51-40.htm>

   [11]  <http://www.uwho.verisignlabs.com/Final-WhoIsPanel-Aug15-Resume
         .pdf>

   [12]  <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/min_
         database.html>

   [13]  <http://www.nanog.org/mtg-0110/lookup.html>












Newton                  Expires January 29, 2003               [Page 19]

Internet-Draft             crisp-requirements                  July 2002


Author's Address

   Andrew L. Newton
   VeriSign, Inc.
   21345 Ridgetop Circle
   Sterling, VA  20166
   USA

   Phone: +1 703 948 3382
   EMail: anewton@verisignlabs.com
   URI:   http://www.verisignlabs.com/








































Newton                  Expires January 29, 2003               [Page 20]

Internet-Draft             crisp-requirements                  July 2002


Appendix A. Glossary

   o  TLD: Initials for "top level domain." Referes to domains in
      DNS[2]that are hierarchically at the level just beneath the root.

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

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

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

   o  operational data: Data necessary to the operation of networks and
      network related services and items.

   o  RIR: Initials for "regional Internet registry."

   o  IRR: Initials for "Internet routing registry."

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

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

   o  privileged entity: A person, or person acting on behalf of an
      organization, with authorization to access data.

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

   o  privileged data: Data accessible by a privileged entities.

   o  non-privileged data: Data accessible by privileged entities and
      non-privileged entities.

   o  forward lookup: a DNS lookup where a domain name is resolved to
      an IP address.

   o  reverse lookup: a DNS lookup where an IP address is resolved to a
      domain name.



Newton                  Expires January 29, 2003               [Page 21]

Internet-Draft             crisp-requirements                  July 2002


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














































Newton                  Expires January 29, 2003               [Page 22]

Internet-Draft             crisp-requirements                  July 2002


Appendix B. Acknowledgements

B.1 Forums

   The proceedings of the following public forums were used as input to
   the scope and requirements for this document: 

   o  whois BOF of the 49th IETF[9]; December 10-15, 2000; San Diego,
      CA, USA

   o  whoisfix BOF of the 51st IETF[10]; August 5-10, 2001; London,
      England

   o  First UWho Consultation[11]; August 15, 2001; Washington, DC, USA

   o  Second UWho Consultation; November 15, 2001; Marina del Rey, CA,
      USA

   o  Third UWho Consultation; November 19, 2001; Washington, DC, USA

   o  DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic

   o  Database WG of RIPE 40[12]; October 1-5, 2001; Praque, Czech
      Republic

   o  General Session of NANOG 23[13]; October 21-23; Oakland, CA, USA

   o  DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands

   o  Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The
      Netherlands

   o  NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida

   o  CENTR General Assembly, February 21-22, 2002; Rambouillet, France

   o  CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis,
      Minnesota, USA

B.2 Working Group

   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
   ietf-not43@lists.verisignlabs.com. To subscribe to this email list,
   send email to ietf-not43-request@lists.verisignlabs.com with a
   subject line of "subscribe". Archives of this list may be found out
   http://lists.verisignlabs.com/pipermail/ietf-not43/.



Newton                  Expires January 29, 2003               [Page 23]

Internet-Draft             crisp-requirements                  July 2002


B.3 Contributions

   Comments, suggestions, and feedback of significant substance have
   been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane
   Kerr, and Cathy Murphy.














































Newton                  Expires January 29, 2003               [Page 24]

Internet-Draft             crisp-requirements                  July 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002). 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.



















Newton                  Expires January 29, 2003               [Page 25]






<<< Chronological Index >>>    <<< Thread Index >>>