2.1.3 Cross Registry Information Service Protocol (crisp)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-02

April Marine <april.marine@nominum.com>
George Michaelson <ggm@apnic.net>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.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-requirements-06.txt
  • - draft-ietf-crisp-iris-dreg-04.txt
  • - draft-ietf-crisp-iris-core-04.txt
  • - draft-ietf-crisp-iris-beep-04.txt
  • - draft-ietf-crisp-iris-areg-04.txt
  • - draft-ietf-crisp-internet-resource-number-req-00.txt
  • No Request For Comments

    Current Meeting Report

    Cross Registry Information Service Protocol WG (crisp)
    Wednesday, November 12 at 1300-1500
    CHAIRS: April Marine <april.marine@nominum.com>
            George Michaelson <ggm@apnic.net>
    Scribe: Cathy Murphy
    [These notes are a summary done by April and George based on Cathy's 
    excellent detailed notes.  The detailed notes were sent to the list. 
    Comments like this one that are added to summarize or clarify are in 
    square brackets so their origin is clear.]
    Name Abbreviations:
    AM  April Marine
    AN  Andy Newton
    CA  Chris Ambler
    CM  Cathy Murphy
    EL  Ed Lewis
    FN  Frederico Neves
    GGM George Michaelson
    GL  Ginny Listman
    JK  John Klensin
    LD  Leslie Daigle
    MK  Mark Kosters
    MS  Marco Sanz
    RS  Richard Shockey
    TH  Ted Hardie
    WM  Bill Manning
     o Welcome and Agenda Bashing - chairs
    - Welcome new co-chair, George Michaelson
    - Ted Hardie (now sheparding AD) was wearing too many hats
    - Scribe is Cathy Murphy
    - Anyone to do jabber log? Ted volunteers.
    - Mail list (currently at 
    ietf-not43@verisignlabs.com) will be moving to IETF servers
    - No agenda changes
    Since last meeting, group came to consensus on IRIS as way forward. Reqts 
    draft in RFC editor queue; some recent comments, but done and not 
     o Outstanding IRIS Issues  - Andy Newton
    AN: These are not the issues sent to mailing list; these have come 
    forward since then. List items can be found in mail archives.
    AM: What's the next step?
    AN: Send to list and see who comments.
    AM: Andy has asked for a co-author for the IRIS documents (for XML)?
    ... no volunteers...
    [Note from April: Later Marcos Sanz agreed to co-edit]
     o Additional Requirements? -  Ginny Listman
    AM: Are you still willing to be point person for this document?
    GL: Shane Kerr has agreed to be the editor going forward.
    [Discussion of best way to move these requirements forward given that we 
    already have a draft req doc in RFC Editor queue.  Decision is to do a 
    "bis" or update of the original req doc, one that totally replaces the 
    first req doc so as to capture all the requirements in one place.]
     o IRIS lightweight transport  -  Andy Newton
    AN: Recently, some discussion about transports on the list. It was 
    brought up before a while back, but is was probably premature to discuss at 
    that time. Now seems like a good time to discuss this.
    [Presentaiton and discussion of the possibility of adding UDP as one of the 
    IRIS transports.]
    GGM: Feel strongly that if it going to proceed, should be done here.
    TH: Agree. What is going to get people to move? Will IRIS-light get 
    people to move? But if what is defined is so similar to whois-like, then 
    worry that will discourage moving.
    AN: Agree with that concern, that if we proceed to UDP, won't ever get to 
    BEEP. But all the other drivers (int'lzation, etc) still will require 
    RS: Is any one clamoring for this?
    AC: Yes, registrars are.
    AM: Would like to take it to the list. [as to whether there is enough 
    demand to see if WG would add it as a work item]
     o Update Charter and Milestones
    Is there agreement on the change to the charter language that allows 
    number resources to be included?
    ...Sense of the room was YES...
    Revised Milestones proposed
    [will send revised charter and milestons to the list--some small changes in 
    milestones from previous msg to the list]
     o Using dreg for registrar-registrar -  Chris Ambler
    CA: Several of aspects of IRIS are to limit queuing due to mining. This 
    works to the detriment of registrars. What we need is a very 
    light-weight registar-to-registrar query mechanism.  So, looking to 
    implement in a number of ways. One idea was to just add a flag in port 43 so 
    that would send back XML . Do we want to proceed with full blown CRISP? 
    Probably, but am approaching now just to do as a light-weight 


    IRIS Open Issues
    IRIS and Application Transports
    What’s In a Number?