2.1.3 Cross Registry Information Service Protocol (crisp)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-10

Ted Hardie <hardie@qualcomm.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
Mailing Lists:
General Discussion: ietf-not43@lists.verisignlabs.com
To Subscribe: ietf-not43-request@lists.verisignlabs.com
In Body: subscribe
Archive: https://lists.verisignlabs.com/mailman/listinfo/ietf-not43
Description of Working Group:
In the standard operation of Internet systems, various labels and data are managed globally -- domain names, IPv4 and IPv6 addresses, etc. From time to time, for operational and administrative purposes, users of the Internet need to be able to find and access registered information associated with those labels.

The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for finding authoritative information associated with a label, a protocol to transport queries and responses for accessing that information, and a first profile (schema & queries) to support commonly-required queries for domain registration information. Backwards compatibility with existing administrative directory services such as WHOIS is not a goal of this effort. Provisioning of data into registry or registrar systems is likewise out of scope -- CRISP provides a uniform access to and view of data that may be held in disparate backend servers. While the framework created will hopefully be sufficiently flexible to allow re-use by other registries/services with related design criteria, those uses will be deferred to the creation of appropriate schema & query profiles at some future date.

The CRISP service definition will define:

o a standard mechanism that can be used to determine the authoritative server(s) for information about a given label

o a single mandatory to implement protocol for transporting application queries and responses, including

o expression of input query

o expression of result sets

o standard expression of error conditions

o authentication and verification of data integrity

o specific data types and queries to be supported in the first supported registry service: a global service for domain registration information access


o Finalized requirements document for the CRISP service

o Document specifying a new protocol, or the use of an existing one, for providing CRISP service (application transport).

o Document specifying required schema elements and queries for domain registration administrative directory queries.

Input documents:

draft-newton-ir-dir-requirements-* draft-newton-iris* draft-hall-ldap-whois*

Goals and Milestones:
OCT 02  Submit requirements document as an Informational RFC
NOV 02  Submit first draft of protocol (use) specification
NOV 02  Submit first draft of domain registration administrative directory services required schema element specification.
APR 03  Submit revised protocol (use) specification document as Proposed Standard
APR 03  Submit revised draft of domain registration administrative directory services required schema element specification as Proposed Standard.
  • - draft-ietf-crisp-lw-core-00.txt
  • - draft-ietf-crisp-lw-dns-00.txt
  • - draft-ietf-crisp-lw-asn-00.txt
  • - draft-ietf-crisp-lw-ipv6-00.txt
  • - draft-ietf-crisp-lw-user-00.txt
  • - draft-ietf-crisp-lw-ipv4-00.txt
  • - draft-ietf-crisp-requirements-04.txt
  • - draft-ietf-crisp-iris-dreg-01.txt
  • - draft-ietf-crisp-iris-core-01.txt
  • - draft-ietf-crisp-iris-beep-01.txt
  • - draft-ietf-crisp-iris-areg-01.txt
  • No Request For Comments

    Current Meeting Report

    Minutes for CRISP, IETF 56
    Wednesday, March 19, 2003
    Reported by: Cathy Murphy
    Chairs: Ted Hardie & April Marine
    Proposed Agenda:
    Agenda Bashing
    Review output from working group last call of requirements draft.
            Andy Newton
    Review of method for selecting protocol
    Call for volunteers for specific evaluation elements
    All other business
            Leslie Daigle to present "IRIS light"; a non-working group item.
    Agenda Accepted
    New Chair (April Marine) introduced
    New Area Advisor (Ned Freed) introduced
    Thanks presented to outgoing Area Advisor (Patrik Falstrom)
    Andy Newton will present a revised Requirements document by April 15, 2003
    Subject to mailing list approval, the group agreed that protocol 
    evaluation will proceed as a staged knock-out, first evaluating for 
    protocol requirements, then for service requirements if no candidate is 
    knocked out in the first evalution.
    To make visible these evaluations, Andy Newton agreed to develop a 
    proposed matrix of the MUST, SHOULD, MAY, requirements.
    Rick Wesson agreed to maintain the matrix once it has been approved.
    Subject to mailing list approval, the protocol proposers will do the 
    initial population of the matrix for their protocols.  These will then be 
    reviewed by the mailing list.  Initial stuckees for the review are:
    	LDAP Matrix Review: Peter Gietz, Richard Shockey
    	IRIS Matrix Review: Ed Lewis, Scott Hollenbeck
    Chairs called for volunteers for additional reviewers; the new deadline 
    will be the matrix being completed and reviewed prior to VIenna.
    After a conversation on bags, Rick Wesson agreed to formulate a set of 
    concerns and send to the list.
    IRIS Light was then presented as an informative reference for the group.


    None received.