draft-ietf-crisp-requirements-05.txt   draft-ietf-crisp-requirements-06.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: November 8, 2003 May 10, 2003 Expires: February 20, 2004 August 22, 2003
Cross Registry Internet Service Protocol (CRISP) Requirements Cross Registry Internet Service Protocol (CRISP) Requirements
draft-ietf-crisp-requirements-05 draft-ietf-crisp-requirements-06
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
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 November 8, 2003. This Internet-Draft will expire on February 20, 2004.
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 45 skipping to change at page 2, line 45
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 . . . . . . . . . . . . . . 13 3.1.12 Protocol and Schema Versioning . . . . . . . . . . . . . . 13
3.1.13 Relay Bag . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.13 Relay Bag . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.14 Privacy Labels . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . . 16 3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . . 17
3.2.4 Serialization Support . . . . . . . . . . . . . . . . . . 17 3.2.4 Serialization Support . . . . . . . . . . . . . . . . . . 18
3.2.5 Result Set Limits . . . . . . . . . . . . . . . . . . . . 18 3.2.5 Result Set Limits . . . . . . . . . . . . . . . . . . . . 18
3.2.6 DNS Delegation Referencing . . . . . . . . . . . . . . . . 18 3.2.6 DNS Delegation Referencing . . . . . . . . . . . . . . . . 19
3.2.7 Distribution for Domain Registry Types . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 20 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
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). The requirements for other registry types will be (Section 2.1). The requirements for other registry types will be made
made available in other memos. The requirements are of both the available in other memos. The requirements are of both the current
current use of these directory services and the desired functionality use of these directory services and the desired functionality based
based on input from relevant forums (Appendix B.1). These on input from relevant forums (Appendix B.1). These requirements are
requirements are not specific to any protocol. Terms used in the not specific to any protocol. Terms used in the definition of
definition of requirements in this document may be found in the requirements in this document may be found in the glossary (Appendix
glossary (Appendix A). 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 17 skipping to change at page 6, line 17
The Internet registries are composed of various communities which The Internet registries are composed of various communities which
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 .ARPA
.ARPA domain). These registries have typically served two main domain). These registries have typically served two main domain
domain functions: as the registry for a gTLD or as a registry for a functions: as the registry for a gTLD or as a registry for a ccTLD.
ccTLD. In some instances, one entity will operate multiple TLD's, In some instances, one entity will operate multiple TLD's, both of
both of the gTLD and ccTLD type. A gTLD or ccTLD domain registry the gTLD and ccTLD type. A gTLD or ccTLD domain registry operator may
operator may be a governmental entity, non-governmental, be a governmental entity, non-governmental, non-commercial entity, or
non-commercial entity, or a commercial entity. 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 data (Appendix A) for operational data for the domain and the contact data (Appendix A) for
the domain. In this model, the registry is typically the interface the domain. In this model, the registry is typically the interface to
to the domain registrant but may also interface with the domain the domain registrant but may also interface with the domain
registrant through domain registrars. The "thin" model domain registrant through domain registrars. The "thin" model domain
registry contains only operational data for domains. In the "thin" registry contains only operational data for domains. In the "thin"
model, contact data for the domain are maintained by a domain model, contact data for the 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
skipping to change at page 7, line 33 skipping to change at page 7, line 33
Local Internet Registries (LIR's) and National Internet Registries Local Internet Registries (LIR's) and National Internet Registries
(NIR's) are sub-registries of RIR's and coordinate the same functions (NIR's) are sub-registries of RIR's and coordinate the same functions
of the RIR's for smaller, more specific geographic regions, sovereign of the RIR's for smaller, more specific geographic regions, sovereign
nations, and localities. nations, and localities.
2.2.3 Internet Routing Registries 2.2.3 Internet Routing Registries
Internet Routing Registries are routing policy databases. Their Internet Routing Registries are routing policy databases. Their
purpose is to provide information helpful in administering Internet purpose is to provide information helpful in administering Internet
routers. Frequently, the syntax and contents are defined by RPSL routers. Frequently, the syntax and contents are defined by RPSL [7].
[7].
IRR's are operated by academic, commercial, governmental, and other IRR's are operated by academic, commercial, governmental, and other
types of organizations, including several of the RIR's. The contents types of organizations, including several of the RIR's. The contents
of the databases vary and reflect the needs of the users directly 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 served (e.g. an ISP may look up route entries added by their
customers to decide whether to accept specific route advertisements customers to decide whether to accept specific route advertisements
they receive). they receive).
Unlike RIR and domain registry data, IRR data is often duplicated Unlike RIR and domain registry data, IRR data is often duplicated
between separate organizations. The IRR data has the unique between separate organizations. The IRR data has the unique
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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.
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 congestion-aware transport mechanisms for
mandatory implementation.
3.1.3 Standard and Extensible Schemas 3.1.3 Standard and Extensible Schemas
3.1.3.1 Protocol Requirement 3.1.3.1 Protocol Requirement
The protocol MUST contain standard schemas for the exchange of data The protocol MUST contain standard schemas for the exchange of data
needed to implement the functionality in this document. In addition, 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 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 needs of this document. Both types of schemas MUST use the same
schema language. The schemas MUST be able to express data elements schema language. The schemas MUST be able to express data elements
with identifying tags for the purpose of localization of the meaning with identifying tags for the purpose of localization of the meaning
of the identifying tags. of the identifying tags.
3.1.3.2 Service Description 3.1.3.2 Service Description
The client-to-server protocol must define a standard set of data The client-to-server protocol must define a standard set of data
structures or schemas to be used when exchanging information. It structures or schemas to be used when exchanging information. It must
must also poses the ability to allow for the use of newer data also poses the ability to allow for the use of newer data structures
structures that are currently nor foreseen by this specification. In that are currently nor foreseen by this specification. In both cases,
both cases, the description and specification of both types of data the description and specification of both types of data structures or
structures or schemas must be done in the same way (i.e. the same schemas must be done in the same way (i.e. the same schema language).
schema language).
The schemas must also be capable of "tagging" data with a unique The schemas must also be capable of "tagging" data with a unique
identifier. This identifier can then be used to localize the name of identifier. This identifier can then be used to localize the name of
that type of data. For instance, a piece of data may have the value that type of data. For instance, a piece of data may have the value
"Bob" and its type identified with the number "5.1". Client software "Bob" and its type identified with the number "5.1". Client software
could use this to display "Name: Bob" in an English locale or could use this to display "Name: Bob" in an English locale or
"Nombre: Bob" in a Spanish locale. "Nombre: Bob" in a Spanish locale.
3.1.4 Level of Access 3.1.4 Level of Access
skipping to change at page 15, line 16 skipping to change at page 15, line 16
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.
3.1.14 Privacy Labels
3.1.14.1 Protocol Requirement
When a value in an answer to a query is given, the protocol MUST be
capable of tagging the value with the following labels:
1. do not redistribute
2. special access granted
The protocol MAY define other values for this purpose, but MUST
define values defined above at a minimum. The protocol MUST be
capable of attaching these labels concurrently.
3.1.14.2 Service Description
Internet registries will have varying policies regarding the access
to their data. Some registries may grant certain classes of users
with access to data that would not normally be given to most users.
In these cases, registries may want to tag the values in these
entries with labels specifying the responsibilities accompanying
these special user rights.
3.2 Domain Specific Functions 3.2 Domain Specific Functions
These functions describe requirements specifically needed by domain These functions describe requirements specifically needed by domain
registries (Section 2.1.1) and domain registrars (Section 2.1.2). registries (Section 2.1.1) and domain registrars (Section 2.1.2).
Requirements specific to other registries (Section 2.2) MUST be Requirements specific to other registries (Section 2.2) MUST be
specified separately. No compliant server operator is required to specified separately. No compliant server operator is required to
support the functions required by every registry type. support the functions required by every registry type.
3.2.1 Lookups 3.2.1 Lookups
skipping to change at page 20, line 4 skipping to change at page 20, line 28
The protocol MAY define other values for this purpose, but MUST The protocol MAY define other values for this purpose, but MUST
define values defined above at a minimum. define values defined above at a minimum.
3.2.8.2 Service Description 3.2.8.2 Service Description
Internet registries will have varying constraints regarding their Internet registries will have varying constraints regarding their
ability to expose certain types of data, usually social information. ability to expose certain types of data, usually social information.
Server operators must have the ability to accommodate this need while Server operators must have the ability to accommodate this need while
client software will be more useful when provided with proper client software will be more useful when provided with proper
explanations. Therefore, depending on policy, a server operator has explanations. Therefore, depending on policy, a server operator has a
a choice between not returning the data at all, signaling a choice between not returning the data at all, signaling a permission
permission error, or indicating a privacy constraint. error, or indicating a privacy constraint.
3.2.9 Internationalization 3.2.9 Internationalization
The schema defining domain related resources MUST conform to RFC 2277 The schema defining domain related resources MUST conform to RFC 2277
[2] regarding textual data. In particular, the schema MUST be able [2] regarding textual data. In particular, the schema MUST be able
to indicate the charset and language in use with unstructured textual to indicate the charset and language in use with unstructured textual
data. data.
The protocol MUST be able to support multiple representations of The protocol MUST be able to support multiple representations of
contact data, with these representations complying with the contact data, with these representations complying with the
skipping to change at page 24, line 9 skipping to change at page 24, line 9
6. IANA Considerations 6. IANA Considerations
IANA consideration for any service meeting these requirements will IANA consideration for any service meeting these requirements will
depend upon the technologies chosen and MUST be specified by any depend upon the technologies chosen and MUST be specified by any
document describing such a service. document describing such a service.
7. Security Considerations 7. Security Considerations
This document contains requirements for the validation of This document contains requirements for the validation of
authenticated entities and the access of authenticated entities authenticated entities and the access of authenticated entities
compared with the access of non-authenticated entities. This compared with the access of non-authenticated entities. This document
document does not define the mechanism for validation of does not define the mechanism for validation of authenticated
authenticated entities. Requirements defined in this document MUST entities. Requirements defined in this document MUST allow for the
allow for the implementation of this mechanism according best common implementation of this mechanism according best common practices.
practices.
The requirement in Section 3.1.4 must be weighed against other The requirement in Section 3.1.4 must be weighed against other
requirements specifying search or lookup capabilities. requirements specifying search or lookup capabilities.
This document contains requirements for referrals and entity This document contains requirements for referrals and entity
references. Client implementations based on these requirements references. Client implementations based on these requirements SHOULD
SHOULD take proper care in the safe-guarding of credential take proper care in the safe-guarding of credential information when
information when resolving referrals or entity references according resolving referrals or entity references according to best common
to best common practices. practices.
This document contains requirements for the distribution of queries This document contains requirements for the distribution of queries
among a mesh of participating service providers. Protocols proposed among a mesh of participating service providers. Protocols proposed
to meet these requirements must be able to protect against the use of to meet these requirements must be able to protect against the use of
that distribution system as a vector of distributed denial of service that distribution system as a vector of distributed denial of service
attacks or unauthorized data mining. attacks or unauthorized data mining.
Normative References Normative References
[1] Mockapetris, P., "Domain names - implementation and [1] Mockapetris, P., "Domain names - implementation and
 End of changes. 

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