Last Modified: 2004-02-19
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.
Deliverables:
- 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.
| 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 |
| RFC | Status | Title |
|---|---|---|
| RFC3707 | I | Cross Registry Internet Service Protocol (CRISP) Requirements |
|
CRISP minutes
Tuesday, 2004-03-02 09:00 to 11:30 CHAIRS: April Marine april.marine@nominum.com George Michaelson ggm@apnic.net Minutes: Shane Kerr o Welcome, Agenda Bashing, Status Update Chairs - 10 min Status: requirements now RFC iris-(core|dreg|beep) about to be submitted for WG last call o Update on latest drafts: draft-ietf-crisp-iris-core-05.txt draft-ietf-crisp-iris-dreg-05.txt draft-ietf-crisp-iris-beep-05.txt 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. |