draft-ietf-crisp-requirements-04.txt   draft-ietf-crisp-requirements-05.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: August 25, 2003 February 24, 2003 Expires: November 8, 2003 May 10, 2003
Cross Registry Internet Service Protocol (CRISP) Requirements Cross Registry Internet Service Protocol (CRISP) Requirements
draft-ietf-crisp-requirements-04 draft-ietf-crisp-requirements-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2003. This Internet-Draft will expire on November 8, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Internet registries expose administrative and operational data via Internet registries expose administrative and operational data via
varying directory services. This document defines functional varying directory services. This document defines functional
requirements for the directory services of domain registries and the requirements for the directory services of domain registries and the
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1.3 Requirements Specification . . . . . . . . . . . . . . . . 4 1.3 Requirements Specification . . . . . . . . . . . . . . . . 4
2. Internet Registry Communities . . . . . . . . . . . . . . 6 2. Internet Registry Communities . . . . . . . . . . . . . . 6
2.1 Domain Name System Registries . . . . . . . . . . . . . . 6 2.1 Domain Name System Registries . . . . . . . . . . . . . . 6
2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 6 2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 6
2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 7 2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 7 2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 7
2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 7 2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 7
2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 7 2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 7
2.2.4 Incident Coordination Contact Registries . . . . . . . . . 7 2.2.4 Incident Coordination Contact Registries . . . . . . . . . 7
2.2.5 Network Edge Resource Registries . . . . . . . . . . . . . 8
2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Service Providers and Network Operators . . . . . . . . . 8 2.4.1 Internet Resource Registrants . . . . . . . . . . . . . . 8
2.4.2 Intellectual Property Holders . . . . . . . . . . . . . . 8 2.4.2 Service Providers and Network Operators . . . . . . . . . 8
2.4.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 9 2.4.3 Intellectual Property Holders . . . . . . . . . . . . . . 8
2.4.4 Certificate Authorities . . . . . . . . . . . . . . . . . 9 2.4.4 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 9
2.4.5 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.5 Certificate Authorities . . . . . . . . . . . . . . . . . 9
2.4.6 Domain Registrants . . . . . . . . . . . . . . . . . . . . 9 2.4.6 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.7 Abusive Users . . . . . . . . . . . . . . . . . . . . . . 9 2.4.7 Abusive Users . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 9 2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 9
3. Functional Requirements . . . . . . . . . . . . . . . . . 10 3. Functional Requirements . . . . . . . . . . . . . . . . . 10
3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 10 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 10 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 10
3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10
3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 11 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 11
3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 12 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 12
3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 12 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 12
3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 12 3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 12
3.1.8 Query of Access Permission . . . . . . . . . . . . . . . . 12 3.1.8 Query of Access Permission . . . . . . . . . . . . . . . . 12
3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 12 3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 12
3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 13 3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 13
3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 13 3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 13
3.1.12 Protocol and Schema Versioning . . . . . . . . . . . . . . 14 3.1.12 Protocol and Schema Versioning . . . . . . . . . . . . . . 13
3.1.13 Relay Bag . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.13 Relay Bag . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 14 3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 15
3.2.1 Lookups . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1 Lookups . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Searches . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.2 Searches . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . . 16 3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . . 16
3.2.4 Serialization Support . . . . . . . . . . . . . . . . . . 17 3.2.4 Serialization Support . . . . . . . . . . . . . . . . . . 17
3.2.5 Result Set Limits . . . . . . . . . . . . . . . . . . . . 17 3.2.5 Result Set Limits . . . . . . . . . . . . . . . . . . . . 18
3.2.6 DNS Delegation Referencing . . . . . . . . . . . . . . . . 18 3.2.6 DNS Delegation Referencing . . . . . . . . . . . . . . . . 18
3.2.7 Distribution for Domain Registry Types . . . . . . . . . . 18 3.2.7 Distribution for Domain Registry Types . . . . . . . . . . 19
3.2.8 Data Omission . . . . . . . . . . . . . . . . . . . . . . 19 3.2.8 Data Omission . . . . . . . . . . . . . . . . . . . . . . 19
3.2.9 Internationalization . . . . . . . . . . . . . . . . . . . 19 3.2.9 Internationalization . . . . . . . . . . . . . . . . . . . 20
4. Feature Requirements . . . . . . . . . . . . . . . . . . . 21 4. Feature Requirements . . . . . . . . . . . . . . . . . . . 21
4.1 Client Authentication . . . . . . . . . . . . . . . . . . 21 4.1 Client Authentication . . . . . . . . . . . . . . . . . . 21
4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 21 4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 21
4.4 Structured Queries and Responses . . . . . . . . . . . . . 21 4.4 Structured Queries and Responses . . . . . . . . . . . . . 21
4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 21 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 21
4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 21 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 21
5. Internationalization Considerations . . . . . . . . . . . 22 5. Internationalization Considerations . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . 24
skipping to change at page 4, line 27 skipping to change at page 4, line 27
definitions of syntax, undocumented security mechanisms, the use of definitions of syntax, undocumented security mechanisms, the use of
other protocols, such as rwhois [5], to fulfill other needs, and other protocols, such as rwhois [5], to fulfill other needs, and
proposals for the use of other technologies such as LDAP [4] and XML. proposals for the use of other technologies such as LDAP [4] and XML.
1.2 Requirements Scope 1.2 Requirements Scope
The scope of the requirements captured in this document relate to the The scope of the requirements captured in this document relate to the
directory services of Internet registries and their related directory services of Internet registries and their related
communities (Section 2.3,Section 2.4, and Section 2.5). This scoping communities (Section 2.3,Section 2.4, and Section 2.5). This scoping
specifically targets the requirements of domain name registries specifically targets the requirements of domain name registries
(Section 2.1) while acknowledging extensibility needs for possible (Section 2.1). The requirements for other registry types will be
future support of the requirements for other registry (Section 2.2) made available in other memos. The requirements are of both the
types. The requirements are of both the current use of these current use of these directory services and the desired functionality
directory services and the desired functionality based on input from based on input from relevant forums (Appendix B.1). These
relevant forums (Appendix B.1). These requirements are not specific requirements are not specific to any protocol. Terms used in the
to any protocol. Terms used in the definition of requirements in definition of requirements in this document may be found in the
this document may be found in the glossary (Appendix A). glossary (Appendix A).
The scope of the requirements in this document are also restricted to The scope of the requirements in this document are also restricted to
access of data from Internet registries. Requirements for access of data from Internet registries. Requirements for
modification, addition, or provisioning of data in Internet modification, addition, or provisioning of data in Internet
registries are out of scope. registries are out of scope.
1.3 Requirements Specification 1.3 Requirements Specification
The requirements captured in this document are for the purpose of The requirements captured in this document are for the purpose of
designing technical specifications. The words used in this document designing technical specifications. The words used in this document
skipping to change at page 6, line 18 skipping to change at page 6, line 18
provide scope for the requirements in this document. These provide scope for the requirements in this document. These
communities can be generalized into the following categories: communities can be generalized into the following categories:
registries, registrars, implementers, end-users, and other actors. registries, registrars, implementers, end-users, and other actors.
2.1 Domain Name System Registries 2.1 Domain Name System Registries
2.1.1 Domain Registries 2.1.1 Domain Registries
Domain registries are responsible for the registration of domains for Domain registries are responsible for the registration of domains for
use with DNS [1] and forward lookups (i.e. does not include the use with DNS [1] and forward lookups (i.e. does not include the
IN-ADDR.ARPA or IP6.ARPA domains). These registries have typically .ARPA domain). These registries have typically served two main
served two main domain functions: as the registry for a gTLD or as a domain functions: as the registry for a gTLD or as a registry for a
registry for a ccTLD. In some instances, one entity will operate ccTLD. In some instances, one entity will operate multiple TLD's,
multiple TLD's, both of the gTLD and ccTLD type. A gTLD or ccTLD both of the gTLD and ccTLD type. A gTLD or ccTLD domain registry
domain registry operator may be a governmental entity, operator may be a governmental entity, non-governmental,
non-governmental, non-commercial entity, or a commercial entity. non-commercial entity, or a commercial entity.
Some ccTLD's have second-level domain registrations similar in nature Some ccTLD's have second-level domain registrations similar in nature
to gTLD's or have distinctly separate entities operating second-level to gTLD's or have distinctly separate entities operating second-level
domain registries similar in nature to gTLD's within the ccTLD. domain registries similar in nature to gTLD's within the ccTLD.
Domain registries usually follow one of two models for conducting Domain registries usually follow one of two models for conducting
registrations of domains. The "thick" model is the more traditional registrations of domains. The "thick" model is the more traditional
model. In a "thick" domain registry, the registry contains both the model. In a "thick" domain registry, the registry contains both the
operational data for the domain and the contact or social data operational data for the domain and the contact data (Appendix A) for
(Appendix A) for the domain. In this model, the registry is the domain. In this model, the registry is typically the interface
typically the interface to the domain registrant but may also to the domain registrant but may also interface with the domain
interface with the domain registrant through domain registrars. The registrant through domain registrars. The "thin" model domain
"thin" model domain registry contains only operational data for registry contains only operational data for domains. In the "thin"
domains. In the "thin" model, contact or social data for the domain model, contact data for the domain are maintained by a domain
are maintained by a domain registrar. registrar.
Domain registries not described in this section (Section 2.1.1) are Domain registries not described in this section (Section 2.1.1) are
not the subject of this document and may have requirements that are not the subject of this document and may have requirements that are
out of scope for this subject matter. out of scope for this subject matter.
2.1.2 Domain Registrars 2.1.2 Domain Registrars
Domain registrars accept domain registrations from registrants on Domain registrars accept domain registrations from registrants on
behalf of domain registries, both "thick" and "thin". In a "thin" behalf of domain registries, both "thick" and "thin". In a "thin"
model registry/registrar system, a domain registrar maintains the model registry/registrar system, a domain registrar maintains the
contact and social data of a domain while the registry maintains the contact data of a domain while the registry maintains the operational
operational data of a domain. In a "thick" model registry/registrar data of a domain. In a "thick" model registry/registrar system, a
system, a domain registrar passes both the operational data and domain registrar passes both the operational data and contact data to
contact data to the registry. Domain registrars may register a the registry. Domain registrars may register a domain on behalf of a
domain on behalf of a registrant in more than one domain registry. registrant in more than one domain registry.
2.2 Other Registries 2.2 Other Registries
This section describes Internet registries other than those listed in
Section 2.1. These descriptions are not definitive and this list is
not absolute. They are provided in this document for informational
purposes only.
2.2.1 Regional Internet Registries 2.2.1 Regional Internet Registries
Regional Internet Registries (RIR's) administer the allocation of IP Regional Internet Registries (RIR's) administer the allocation of IP
address space and autonomous system numbers. Each RIR serves a address space and autonomous system numbers. Each RIR serves a
specific geographic region, and collectively they service the entire specific geographic region, and collectively they service the entire
Internet. Each RIR is a membership-based, non-profit organization Internet. Each RIR is a membership-based, non-profit organization
that facilitates and implements global addressing policy based on the that facilitates and implements global addressing policy based on the
direction of their regional community. direction of their regional community.
2.2.2 Local Internet Registries 2.2.2 Local Internet Registries
skipping to change at page 8, line 6 skipping to change at page 8, line 11
2.2.4 Incident Coordination Contact Registries 2.2.4 Incident Coordination Contact Registries
Incident coordination contact registries allow operators of network Incident coordination contact registries allow operators of network
resources such as network infrastructure, network names, or network resources such as network infrastructure, network names, or network
services to register contact information for the purpose of providing services to register contact information for the purpose of providing
a means of incident notification. Using this type of registry, an a means of incident notification. Using this type of registry, an
operators of network resources are provided information for operators of network resources are provided information for
contacting the operator of another network resource from which an contacting the operator of another network resource from which an
incident may be occurring. incident may be occurring.
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 [5] servers
operated by networks to describe the assignment of address space
allocated by RIR's or LIR's and whois [6] servers operated by
networks to specifically announce routing policy of that network.
2.3 Implementers 2.3 Implementers
Implementers of client software are often either affiliated with Implementers of client software are often either affiliated with
large network operators, registry operators, or commercial entities large network operators, registry operators, or commercial entities
offering value-added services, or are general citizens of the offering value-added services, or are general citizens of the
Internet. Much of the client software for use with the directory Internet. Much of the client software for use with the directory
services of Internet registries is either freely available, open services of Internet registries is either freely available, open
source, or both, or available as a service. Implementers of server source, or both, or available as a service. Implementers of server
software are often affiliated with operators or commercial entities software are often affiliated with operators or commercial entities
specializing in the out-sourcing of development for Internet specializing in the out-sourcing of development for Internet
registries. registries.
2.4 End Users 2.4 End Users
2.4.1 Service Providers and Network Operators This section describes the many type of end-users. Individuals and
organizations may have multiple roles and may concurrently occupy
many of the categories.
2.4.1 Internet Resource Registrants
Entities given authority over an Internet resource via purchase,
lease, or grant from an Internet registry, either directly or via the
services of a registrar.
2.4.2 Service Providers and Network Operators
Service providers and network operators provide connectivity, Service providers and network operators provide connectivity,
routing, and naming services to many other entities, some commercial routing, and naming services to many other entities, some commercial
and some non-commercial, both large and small. Their operational and and some non-commercial, both large and small. Their operational and
administrative staff often interact with Internet registries on administrative staff often interact with Internet registries on
behalf of other end-users. Service providers and network operators behalf of other end-users. Service providers and network operators
interact with all of the Internet registry operators outlined in this interact with all of the Internet registry operators outlined in this
document on a frequent and consistent basis. For example, network document on a frequent and consistent basis. For example, network
operators use the directory services of Internet registries to operators use the directory services of Internet registries to
determine contact information for network resources that have determine contact information for network resources that have
technical problems. technical problems.
2.4.2 Intellectual Property Holders 2.4.3 Intellectual Property Holders
A number of parties, such as trademark, service mark and intellectual A number of parties, such as trademark, service mark and intellectual
property holders, individuals, governments and other geopolitical property holders, individuals, governments and other geopolitical
entities, have some legal rights on certain alphanumeric strings. entities, have some legal rights on certain alphanumeric strings.
They use the directory services of Internet registries, mostly domain They use the directory services of Internet registries, mostly domain
registries and registrars, for purposes of maintaining and defending registries and registrars, for purposes of maintaining and defending
claims to domain names consistent with applicable laws and claims to domain names consistent with applicable laws and
regulations. regulations.
2.4.3 Law Enforcement 2.4.4 Law Enforcement
Law enforcement agencies use the directory services of Internet Law enforcement agencies use the directory services of Internet
registries to find information used to carry out the enforcement of registries to find information used to carry out the enforcement of
laws within their jurisdictions. laws within their jurisdictions.
2.4.4 Certificate Authorities 2.4.5 Certificate Authorities
Certificate authorities use the directory services of Internet Certificate authorities use the directory services of Internet
registries as part of their verification process when issuing registries as part of their verification process when issuing
certificates for Internet named hosts. certificates for Internet named hosts.
2.4.5 DNS Users 2.4.6 DNS Users
Users of the Internet have client software that resolves domain names Users of the Internet have client software that resolves domain names
to IP addresses. Often when trouble occurs in the resolution process to IP addresses and IP addresses to domain names. Often when trouble
of DNS, these users trouble shoot system problems with the aid of occurs in the resolution process of DNS, these users trouble shoot
information from the directory services of Internet registries. 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.4.7 Abusive Users 2.4.7 Abusive Users
The administrative directory services of Internet registries are The administrative directory services of Internet registries are
often the target of practices by abusive users. Using information often the target of practices by abusive users. Using information
obtained from Internet registries, abusive users undertake certain obtained from Internet registries, abusive users undertake certain
activities that are counter to the acceptable use of the information activities that are counter to the acceptable use of the information
as intended by a registry, registrar, or registrant. Many times, as intended by a registry, registrar, or registrant. Many times,
these practices violate law in the jurisdiction of the user, these practices violate law in the jurisdiction of the user,
registry, registrar, or registrant. One example is the use of registry, registrar, or registrant. One example is the use of
skipping to change at page 10, line 16 skipping to change at page 10, line 16
Functional requirements describe an overall need or process for which Functional requirements describe an overall need or process for which
the directory service is used by an Internet registry to fulfill its the directory service is used by an Internet registry to fulfill its
obligations to provide access to its respective customers, members, obligations to provide access to its respective customers, members,
or other constituents. This section describes requirements in the or other constituents. This section describes requirements in the
manner specified in Section 1.3. manner specified in Section 1.3.
3.1 Base Functions 3.1 Base Functions
This section describes basic directory service protocol requirements This section describes basic directory service protocol requirements
for domain name (Section 2.1) and other (Section 2.2) registries. for Internet registries. Additional requirements, specific to domain
Additional requirements, specific to domain registries, are described registries, are described in Domain Specific Functions (Section 3.2).
in Domain Specific Functions (Section 3.2).
3.1.1 Mining Prevention 3.1.1 Mining Prevention
In order to prevent the inappropriate acquisition of data from an In order to prevent the inappropriate acquisition of data from an
Internet registry's directory service, many servers will limit the Internet registry's directory service, many servers will limit the
amount of data that may be returned in a fixed time period from a amount of data that may be returned in a fixed time period from a
server to a client. This will most likely be especially true for server to a client. This will most likely be especially true for
anonymous access uses (see Section 3.1.4). anonymous access uses (see Section 3.1.4).
The limits placed on differing types of data or applied depending The limits placed on differing types of data or applied depending
upon access status will most likely differ from server to server upon access status will most likely differ from server to server
based on policy and need. Support for varying service models in the based on policy and need. Support for varying service models in the
effort to limit data and prevent data mining may or may not have a effort to limit data and prevent data mining may or may not have a
direct impact on the client-to-server protocol. direct impact on the client-to-server protocol.
Section 3.2.5 also contains protocol requirements which are relevant
to client/server interaction in certain domain registry service
models.
3.1.2 Minimal Technical Reinvention 3.1.2 Minimal Technical Reinvention
The protocol MUST NOT employ unique technology solutions for all The protocol MUST NOT employ unique technology solutions for all
aspects and layers above the network and transport layers and SHOULD aspects and layers above the network and transport layers and SHOULD
make use of existing technology standards where applicable. The make use of existing technology standards where applicable. The
protocol MUST employ the use of network and transport layer standards protocol MUST employ the use of network and transport layer standards
as defined by the Internet Engineering Task Force. The protocol MUST as defined by the Internet Engineering Task Force. The protocol MUST
define one or more transport mechanisms for mandatory implementation. define one or more transport mechanisms for mandatory implementation.
3.1.3 Standard and Extensible Schemas 3.1.3 Standard and Extensible Schemas
skipping to change at page 14, line 29 skipping to change at page 14, line 27
The service should allow end-systems using different protocol The service should allow end-systems using different protocol
versions to fallback to a mutually supported protocol version. If versions to fallback to a mutually supported protocol version. If
this is not possible, the service must provide a meaningful error this is not possible, the service must provide a meaningful error
which indicates that this is the specific case. which indicates that this is the specific case.
The service must suggest negotiation and/or recovery mechanisms for The service must suggest negotiation and/or recovery mechanisms for
clients to use when an unknown schema version is received. clients to use when an unknown schema version is received.
3.1.13 Relay Bag 3.1.13 Relay Bag
The term "bag" in this section describes a flexible container which
may contain unspecified data.
3.1.13.1 Protocol Requirement 3.1.13.1 Protocol Requirement
When issuing a referral, the protocol MUST be capable of supplying a When issuing a referral, the protocol MUST be capable of supplying a
relay bag from the server to the client, and the protocol MUST be relay bag from the server to the client, and the protocol MUST be
capable of allowing the client to submit this relay bag with a query capable of allowing the client to submit this relay bag with a query
to the referred server. The use of the relay bag MUST be OPTIONAL. to the referred server. The use of the relay bag MUST be OPTIONAL.
The protocol MUST NOT make any assumptions regarding the contents of The protocol MUST NOT make any assumptions regarding the contents of
the relay bag, but the relay bag MUST be described using the schema the relay bag, but the relay bag MUST be described using the schema
language of the protocol. language of the protocol.
The protocol MUST provide different error messages to indicate
whether the bag is of unrecognized format (permanent failure), if it
contains unacceptable data (permanent failure), or if it contains
data that means processing is refused at this time (transient
failure).
There MUST be no more than one bag per referral. The protocol MUST
NOT make an association or linkage between successive bags in a
referral chain.
The client MUST pass the bag as part of any query made to a referrant
server as a result of a referral.
3.1.13.2 Service Description 3.1.13.2 Service Description
In some models where service coordination among participating server In some models where service coordination among participating server
operators is utilized, there might be needs to allow a referring operators is utilized, there might be needs to allow a referring
server to pass operator-to-operator coordination data along with the server to pass operator-to-operator coordination data along with the
referral to the referent server. Such needs might be auditing or referral to the referent server. Such needs might be auditing or
tracking. This feature requirement allows a server to pass to the tracking. This feature requirement allows a server to pass to the
client a flexible container of unspecified data ("bag") that the client a flexible container of unspecified data ("bag") that the
client should pass to the referent server. The bag has no meaning to client should pass to the referent server. The bag has no meaning to
the client. the client.
skipping to change at page 15, line 29 skipping to change at page 15, line 44
of a nameserver. of a nameserver.
3. Domain lookup given a fully-qualified domain name. 3. Domain lookup given a fully-qualified domain name.
See Section 3.2.3 for the requirements regarding the expected return See Section 3.2.3 for the requirements regarding the expected return
values. values.
3.2.1.2 Service Description 3.2.1.2 Service Description
These lookups are all single index queries and should produce zero or These lookups are all single index queries and should produce zero or
only one result. only one entity.
Depending on the policy and need of an Internet registry, a server Depending on the policy and need of an Internet registry, a server
operator may not allow all or any of these lookups to return part or operator may not allow all or any of these lookups to return part or
all of the information. See Section 3.2.3. all of the information. See Section 3.2.3.
3.2.2 Searches 3.2.2 Searches
3.2.2.1 Protocol Requirement 3.2.2.1 Protocol Requirement
The protocol MUST contain the following search functions: The protocol MUST contain the following search functions:
skipping to change at page 28, line 16 skipping to change at page 28, line 16
o TLD: Initials for "top level domain." Referes to domains in DNS o TLD: Initials for "top level domain." Referes to domains in DNS
[1]that are hierarchically at the level just beneath the root. [1]that are hierarchically at the level just beneath the root.
o ccTLD: Initials for "country code top level domain." TLD's which o ccTLD: Initials for "country code top level domain." TLD's which
use one of the two character country codes defined by ISO. use one of the two character country codes defined by ISO.
o gTLD: Initials for "generic top level domain." TLD's that do not o gTLD: Initials for "generic top level domain." TLD's that do not
use one of the two character country codes defined by ISO. use one of the two character country codes defined by ISO.
o social data: Data containing names and contact information (i.e. o contact data: Data containing names and contact information (i.e.
postal addresses, phone numbers, e-mail addresses) of humans or postal addresses, phone numbers, e-mail addresses) of humans or
legal entities. legal entities.
o operational data: Data necessary to the operation of networks and o operational data: Data necessary to the operation of networks and
network related services and items. network related services and items.
o RIR: Initials for "regional Internet registry." o RIR: Initials for "regional Internet registry."
o IRR: Initials for "Internet routing registry." o IRR: Initials for "Internet routing registry."
skipping to change at page 30, line 11 skipping to change at page 30, line 11
ietf-not43@lists.verisignlabs.com. To subscribe to this email list, ietf-not43@lists.verisignlabs.com. To subscribe to this email list,
send email to ietf-not43-request@lists.verisignlabs.com with a send email to ietf-not43-request@lists.verisignlabs.com with a
subject line of "subscribe". Archives of this list may be found out subject line of "subscribe". Archives of this list may be found out
http://lists.verisignlabs.com/pipermail/ietf-not43/. http://lists.verisignlabs.com/pipermail/ietf-not43/.
B.3 Contributions B.3 Contributions
Comments, suggestions, and feedback of significant substance have Comments, suggestions, and feedback of significant substance have
been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr, been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr,
Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric
Hall, Patrick Mevzek, Marcos Sanz, and Vittorio Bertola. Hall, Patrick Mevzek, Marcos Sanz, Vittorio Bertola, George
Michaelson, and Tim Christensen.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/