2.1.3 Cross Registry Information Service Protocol (crisp)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-19

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: crisp@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/crisp
Archive: https://www1.ietf.org/mail-archive/working-groups/crisp/current/maillist.html
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 nformation 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,

- a first profile (schema & queries) to support commonly-required queries for domain registration information,

- a second profile (schema & queries) to support commonly-required queries for numbering resource information. ("numbering resources" is used to refer to IP addresses and ASNs)

The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future to other types of registries beyond those specifically considered by the group.

Specific topics that are NOT goals of this WG are:

- Backwards compatibility with existing administrative directory services such as WHOIS.

- Provisioning of data into registry or registrar systems. CRISP provides a uniform access to and view of data that may be held in disparate backend servers.

The CRISP service definition will define:

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

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

- expression of input query

- expression of result sets

- standard expression of error conditions

- authentication and verification of data integrity

- specific data types and queries to be supported in the supported registry services.


- Requirements document as an Informational RFC. (previously submitted)

- First draft of protocol (use) specification. (previously submitted)

- First draft of domain registration administrative directory services required schema element specification. (previously submitted)

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

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

- Document specifying required schema elements and queries for numbering resources registration administrative directory queries.

Goals and Milestones:
Done  Submit requirements document as an Informational RFC
Done  Submit first draft of protocol (use) specification
Done  Submit first draft of domain registration administrative directory services required schema element specification.
Jan 04  Submit revised protocol (use) specification document as Proposed Standard
Jan 04  Submit revised draft of domain registration administrative directory services required schema element specification as Proposed Standard.
Mar 04  Submit first draft of IP address registration administrative directory services required schema element specification
Jun 04  Submit revised draft of IP address registration administrative directory services required schema element specification as Proposed Standard
  • - draft-ietf-crisp-iris-dreg-05.txt
  • - draft-ietf-crisp-iris-core-05.txt
  • - draft-ietf-crisp-iris-beep-05.txt
  • - draft-ietf-crisp-iris-areg-05.txt
  • - draft-ietf-crisp-internet-resource-number-req-00.txt
  • Request For Comments:
    RFC3707 I Cross Registry Internet Service Protocol (CRISP) Requirements

    Current Meeting Report

    CRISP minutes
    Tuesday, 2004-03-02 09:00 to 11:30

    April Marine april.marine@nominum.com
    George Michaelson ggm@apnic.net

    Minutes: Shane Kerr

    o Welcome, Agenda Bashing, Status Update
    Chairs - 10 min


    requirements now RFC
    iris-(core|dreg|beep) about to be submitted for WG last call
    o Update on latest drafts:




    Changes centered around XML mechanics:
    Andy Newton - 30 min

    Changes centered around internationalization and language issues:
    Marcos Sanz - 30 min
    In regards to the E.164 specification for globally routable phone number formats, the following comments were made:

    George Michaelson suggests *requiring* E.164 would be "bold and useful".

    Marcos does not want to eliminate potential users.

    Shane suggests it's not hard and makes it hard on client users.

    Andy notes that domain registries exist who don't have valid data.

    Jakob Schlyter notes that a '+' is enough to differentiate between E.164 and other formats.

    Richard Shockey specifies that a '+' means E.164, and otherwise not.

    Consensus: if use a '+', the data MUST be in E.164 format

    o Next Steps - 10 min

    April says these docs will be sent to WG last call within 2 weeks.

    o Status of draft-ietf-crisp-iris-areg-05.txt

    Ed Lewis stars as Cathy Murphy - 20 mins

    Ted Hardie: what about registries "below" the RIR? Would the "number resource registry" point to the RIR or the other organization?

    Ed: don't know, can't remember

    Ted: As long as it's consistent, it doesn't matter

    George: We should specify

    Marcos: Useful if areg and dreg could concur on definitions? For example, contact objects?

    Andy: I don't know. Don't want to weigh down RIRs with domain registry policy.

    Shane: Can we reference the dreg from the areg?

    Andy: I don't think it buys you a lot.

    John Klensin: Why are we using first name, middle name, last name?

    Ed: We removed that and replaced with a "common name".

    John: We need a "surname" field, for sorting and searching. If we can do better, we should, but we need something.

    George: There is an IETF RFC that references this. I will look for this.

    Patrik [jabber]: People interested in name conversion should look at RFC2426, RFC2218

    Shane: pretty much done with address requirements, will send in a few weeks

    o Nesting text for IP ranges

    Engin Gunduz - 5 mins

    Engin: Last week sent text to mailing list. Part was included in areg, the rest will go into address requirements. Includes what we think are all address registry needs. Defines less specific, more specific, etc. Covers requirements for searching on these, for RIPE NCC.

    Andy: Need to change more/less/etc. terminology to understand equivalences.

    George: Need to do more to cover cases that don't fit the more/less/etc. behavior?

    Andy: Yes. Maybe two more terms to describe the administrative-only relationships.

    o Other topics (if any arise)

    Shane: Interested in what the plans are for production services.

    John: Wants to know what the feedback is, to explain to GNSO where we are.

    Patrik: bringing to RIPE meeting in May?

    Shane: Yes

    Scott Hollenbeck: what is the question?

    Shane: what services you will be bringing on-line, and when? folks pls discuss after adjourn.


    IRIS-(CORE|DREG|BEEP)-05 XML Changes
    CORE, BEEP, DREG from 04 to 05: I18N and L10N
    Updates to draft-ietf-crisp-iris-areg