Last Modified: 2004-06-17
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 |
|
Minutes of the crisp WG meeting at IETF 60
Recorded by: Geoffrey Sisson CHAIRS: April Marine George Michaelson Name Abbreviations: AM April Marine AN Andy Newton CM Cathy Murphy EG Engin Gunduz DB Dave Blacka MS Marco Sanz RML Robert Martin-Legene SK Shane Kerr SS Sanjaya TC Tim Christensen TH Ted Hardie o Welcome, Agenda Bashing, Status Update AM: - Meeting mostly to discuss -areg - WG is a little late on milestones - IRIS docs -core, -beep, -dreg now with RFC editor - Last big goal is -areg ------------------------------------------------------------------------ o Status of draft-ietf-crisp-iris-areg-05.txt Presentation (SK): Changes to -areg SK: -Three basic changes: queries, results, and URI resolution 1. Queries: - Removed <beginsWith>, <endsWith> from <findContacts> query - not considered useful - Separated <findOrganizations> from <findNetworks>/<findAutonomousSystems> query - Decided search by name for address resources doesn't make sense - Removed all refs to CIDR, same as <startAddress>, <endAddress> 2. Results: - No human-friendly name or CIDR for networks - Added URI for network type info TH: Adding URI limits number of schemas? SK: Thinking HTTP. TH: If this is really for HTTP/HTTPS, should say so in spec? SK: Good idea. AN: Wasn't this discussed on the list? Originally enumerated, then decided not to, now saying need URI. SK: Often user isn't going to want 40 page description of what ALLOCATED PA means. Specifying meaning is over-specifying. AN: Would string and URI work? SK: Yes. SK: - Removed IP address from <nameServer> element - Removed human-friendly names from ASes--similar to network, so may be nested, etc. - Some changes to nesting text - Overlaps that are non-nested are forbidden - Added more examples to make very clear 3. Location URI resolution - Removed bottom-up resolution - proposing crisp.nro.net as WKS - Not in text yet, but strong proposal - all queries to start at well-known nameserver, move out of the DNS unless some contention about this. Will send as proposal to list. TH: Seems fragile, why was it done this way? AN: Why fragile? TH: No ability to change starting point. AN: This is just standard way, not only way. SK: One thing missing is AS numbers--no way to represent them in the DNS. Issue in IPv4 space, problem with redelegations, if split over multiple RIRs. TH: Is concern that it would look like delegation from IANA to RIR? SK: Exactly. Also similar to the /7 delegation problem: user can enter any IP range and ask for lookup. If /7 lookup, not clear how this is going to work. Going into the DNS doesn't buy much. Caching is nice. MS: Can do this with DNS. SK: You can, but don't know what you gain. More complex from client POV. AN: Doesn't match queries, many corner cases. Within RIRs is easiest thing to do, too. SK: - Summary: No real major changes. AM: Some discussion of diffs required on mailing list. Then draft. Then WGLC. DB: Target date? AM: Revamp. Submit. WGLC. Other changes will be needed too. DB: Adding in WKS will get hackles up. Be prepared, ADs will be on this. Not good for WG. I like it but don't want ADs to bounce it. SK: Can add four pages to doc to explain. AN: Doesn't hurt. Avoids confusion. DB: So this will get us back on track? AM: No way to get back on track w/o turning calendar back :-) ------------------------------------------------------------------------ o Discussion of the More/Less stuff Presentation (AN): "Least, Less, More, Most" Fun AN: - On list had discussion about specificity of request. Started because DB and AN tried to implement but disagreed. AN discussed with SK, some confusion about what some of terms meant. - Tree view of networks can be confusing. Address space view better. [skipping slides on more, less specific] - Mailing list discussion on lowest/highest level of authority--could not find definition. Implementation: Started w/ radix tree - Confusion of given two networks, given two IP addresses - if so, then how do you find the two? Presentation (SK): Nesting by Example SK: - Definitions are a bit vague, latest revision of -areg has examples to clarify. - Created virtual database of address allocations and example queries: - First query: Exact Match (endpoint match) - Second query: All More Specifics - (exact matches are not considered "more specific" by definition) - Third query: One Level More Specifics - Useful for users to determine how many networks are used - Least specific - Fourth query: All Less Specifics - In this case do include less specific - Fifth query: One Level Less Specifics - (those are the core ones) - Also: - Closest Match - Exact Match - If not, find closest match (how RIPE DB works) - Two other types: - Closest Match 2 - RIPE allows, ARIN doesn't allow this case. DBs retain this relationship. - Find Parent (query argument is a handle) - also opposite works AN: Does RIPE DB do parent/child? SK: No. Child is same as more specific. CM: In previous version exact matches were included, not excluded? AM: Sort of weird to have it match one way, not the other way. EG: Yes, but changed to match our current implementation. CM: Breaks ours! EG: Don't know why it's this way. CM: What if start/end is not provided? SK: Then start equals end; all less specific will see everything--up to 33 networks! SS: It's possible to have these overlaps? SK: Not in RIPE or APNIC DBs, but yes in other DBs. DB: Very unsatisfying that two queries have different behaviors. SK: If you consider it, you will start having to do multiple queries. Description is close to optimal for what clients will do. DB: Classic Cisco vs. Juniper discussions. AN: But we're engineers, not mathematicians. SK: Examples are supposed to be illustrative, not exhaustive. SK: 80% of queries to RIPE DB are for IP match. So most important case. Can send e-mail to RIRs/IANA for more general data? Average user will be using web form, can click on button to refine. AN: Agree with SK. AM: May be trying to guess things here. TC: 80% probably about right. Actually 100% for ARIN since don't currently support ranges. SK: Always want to deconstruct. TC: But have nine round-trips to work around. Also have to see branches that are unleaved. Won't know certain ranges exist unless a lot of extra work is done. (Use case was put on list.) AM: So looks like we have a gap. Has to go to list. ??: Same behavior as if query for each IP address in range. Mimic logic. AM: Have to call time. Take to list. Except for this one use case, we are clear on the behavior. ------------------------------------------------------------------------ o Mention of draft-newton-crisp-iris-dchk-00.txt AN: - dchk: light-weight domain availability check - Two components, not married to each other: - UDP - LWZ - Similar to LWZ ideas - Correctly uses DEFLATE - dchk is a scaled-down version of dreg - No new queries or results - Strict subset of dreg for code reuse AN: Is this useful? ??: Would it be useful to have dates? AN: It's more than "yes/no", but can be "yes/no". Dates, etc. are optional. ??: Who is supposed to use dchk? AN: Use case is fast queries for domain availability. Not intended to replace EPP. RML: Registrars love TCP. Only thing they can do. 500 registrars in .dk all use WHOIS, not DNS lookup. AN: But DNS lookup isn't the same thing. AM: Who's read the draft? [few] No one thinks it's a pile of crap? [no] SK: UDP queries also useful in dreg space. AN: Agree, is reusable. ------------------------------------------------------------------------ o Other topics (if any arise) [none] |