CRISP Requirements Discussion draft-ietf-crisp-requirements-02.txt Andrew Newton 55 th IETF, November 19, 2002 Atlanta, GA

7 Security Considerations Option 1: append This document contains requirements for the distribution of queries against a mesh of participants and the possible generation and distribution of index hints both of which could be used in the development of DDoS attacks against the entire mesh or used to create data mining efforts by Direct Marketers (see Section 2.4.7)

7 Security Considerations Option 2: append This document contains requirements for the distribution of queries among a mesh of participating service providers. Protocols proposed to meet these requirements must be able to protect against the use of that distribution system as a vector of DDoS attacks or unauthorized data mining.

3.2.4 Domain Information Lookup Option 1: append The domain information set MUST be able to express and represent arbitrary information and extensions on a individual registry/registrar basis such as license agreements, authorized use policies or extended status notifications and/or marketing/for sale notices.

3.2.4 Domain Information Lookup Option 2: append The domain information set MUST be able to express arbitrary textual information for extensions on a individual service instance basis. Examples of such information are license agreements, authorized use policies, extended status notifications, marketing/for sale notices, and URI references to other sources.

3.2.9 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. This allows the service to operate when an operator chooses not to take advantage of DNS label referencing and during periods of transient or erroneous state of DNS configuration.DNS

3.2.9 DNS Label Referencing Nobody disagrees with it (once it has been explained to them) Nobody likes how it is worded Nobody has suggested alternate text

2.4.7 Abusive Users Option 1: add Abusive users use the directory services of Internet registries as a source of addresses, postal addresses and telephone numbers. Often a direct marketer as associated with junk postal mail, spam/uce and dinner time telephone solicitations.

2.4.7 Abusive Users Option 2: add The directory services of Internet registries are often the target of practices by abusive users. Using information obtained from Internet registries, abusive users undertake certain activities that are counter to the acceptable use of the information as intended by a registry, registrar, or registrant. Many times, these practices violate law in the jurisdiction of the user, registry, registrar, or registrant. One example is the use of Internet registry information for the use of sending unsolicited commercial .

3.2.6 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. Option 1: Since is out of band and out of scope lets remove it. If an entity wishes to use the schemas defined by crisp for escrow that’s fine but escrow has requirements unto its self that may be in opposition to the requirements under discussion.

3.2.6 Escrow Support Option 2: rewording The CRISP schema MAY be usable in other protocols or support systems. As an example, a registrar MAY choose to use the CRISP schema as part of an off-line, out-of-band escrow service in order to enhance the ability to reuse the escrowed data in systems with disparate backed servers"

3.2.6 Serialization Support Option 3: rewording The schemas used by the service SHOULD be capable of off-line serialization. Off-line serialization allows for implementation independent operations such as backup and recovery, load-balancing, etc. This MAY also make possible data escrow capabilities and other usages, however such usages are out of the scope of this document.

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

3.1.8 Query of Access Levels Option 1: reword 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 MUST provide a mechanism allowing a client to determine if a query will be denied before the query is submitted according to the appropriate policies of the operator.

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.4 Level of Access Option 1: rework Implies only two levels of access. Rework so that there may be multiple levels of access. No text yet proposed.

3.1.9 Authentication Distribution The service MUST NOT require any Internet registries to participate in any particular distributed authentication system. The service SHOULD allow the participation by an Internet registry in distributed authentication by many centralized authorities.

3.1.9 Authentication Distribution Option 1: reword The service MUST NOT require any Internet registries to participate in specific authentication systems. The service SHOULD allow the participation by an Internet registry in federated, distributed authentication system of their choosing.

3.2.3 Domain Registrant Search The service MUST provide the capability of searching for registrants by exact name match or a reasonable name subset. This search must comply with Result Set Limits.Result Set Limits The service MUST provide a mechanism to distribute this search across all applicable domain registries and registrars. The service SHOULD have a means to narrow the scope of a search to a specific TLD. The service MUST be able to specify to the client an empty result set should the search yield no results.

3.2.3 Domain Registrant Search Option 1: reword The service MUST provide a lightweight mechanism to distribute this search across applicable domain registries and registrars. The service SHOULD have a means to narrow the scope of a search to a specific TLD. The service MUST provide a mechanism to restrict the scope of a search to specific TLDs, registrars and registries. The service SHOULD provide a mechanism for operators to opt-out of this search or series of searches. The service SHOULD NOT distribute queries to operators that have opted out. The service MUST be able to specify to the client an empty result set should the search yield no results.

3.2.3 Domain Registrant Search Option 2: modify option 1 Rework language concerning opt-out so as not to imply an inter-service provider protocol. Such a protocol would be out of scope.

3.2.3 Domain Registrant Search Option 3: rework Remove second paragraph of Add a base requirement (in the 3.1 section) specifying that the following for referrals that they 1) must not be “generic”, 2) must have context and 3) possess the ability to pass back CRISP-opaque tokens.

3.2.5 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.5 Nameserver Search Option 1: remove 10,000 & 100,000+ host names on one nameserver make it useless Allows one to recreate a non-published zone file when lots of data mining is allowed. Option 2: modify Make reference to Section Data Mining.

Query Settlements Option 1: add Any search mechanism used to distribute a query to all applicable domain registries and registrars for Nameserver Search (3.2.5) or Domain Registrant Search (3.2.3) MUST contain provisions for cost recovery through a settlements mechanism.

Query Settlements Option 2: Out Of Scope Option 3: Specify the use of CRISP-transparent transaction tokens. Uses of the tokens for financial settlement or other uses are out of scope.