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.
- 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|
|RFC3707||I||Cross Registry Internet Service Protocol (CRISP) Requirements|
Tuesday, 2004-03-02 09:00 to 11:30
April Marine email@example.com
George Michaelson firstname.lastname@example.org
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?
Scott Hollenbeck: what is the question?
Shane: what services you will be bringing on-line, and when? folks pls discuss after adjourn.