2.1.3 Cross Registry Information Service Protocol (crisp)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-27


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

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

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: http://www.ietf.org/mail-archive/web/crisp/index.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

- 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

- 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.
Done  Submit revised protocol (use) specification document as Proposed Standard
Done  Submit revised draft of domain registration administrative directory services required schema element specification as Proposed Standard.
Done  Submit first draft of IP address registration administrative directory services required schema element specification
Done  Submit revised draft of IP address registration administrative directory services required schema element specification as Proposed Standard
Jan 06  Submit the following drafts for IESG review (Proposed Standards)
Jan 06  A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS) (Submit to IESG review for Proposed Standard)
Jan 06  A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service (Submit to IESG review for Proposed Standard)
Jan 06  A Common Schema for Internet Registry Information Service Transfer Protocols (Submit to IESG review for Proposed Standard)
Jan 06  XML Pipelining with Chunks for the Information Registry Information Service (Submit to IESG review for Proposed Standard)


  • draft-ietf-crisp-iris-areg-12.txt
  • draft-ietf-crisp-iris-dchk-03.txt
  • draft-ietf-crisp-iris-lwz-04.txt
  • draft-ietf-crisp-iris-areg-urires-01.txt
  • draft-ietf-crisp-iris-common-transport-02.txt
  • draft-ietf-crisp-iris-xpc-02.txt

    Request For Comments:

    RFC3707 I Cross Registry Internet Service Protocol (CRISP) Requirements
    RFC3981 Standard IRIS - The Internet Registry Information Service (IRIS) Core Protocol
    RFC3982 Standard IRIS - A Domain Registry (dreg) Type for the Internet Registry Information Service
    RFC3983 Standard IRIS - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)

    Current Meeting Report


    April: areg-12 was (at last minute) submitted to AD. Got a lot of feedback from Scott & Ted so far.

    Technically this was the last milestone. And yet, still have some drafts. New drafts still basically fit under charter.

    Andy: [gives presentation on his 4! drafts] Update on LWZ, XPC and DCHK.

    LWZ, XPC are transport drafts + common-transport.

    XPC changes: bit order clarifications, other clarifications
    LWZ changes: bit order clarifications
    DCHK changes: added date/time elements that were missing from DCHK but in DREG

    GGM: where are you in implementation?

    Andy: haven't implemented these last changes but everything else. Other's have done some implementation.

    Frederico: we have initial implement of lwz, xpc and dreg. We have added some comments. Some more will be forthcoming

    Andy asks Fred if they would have implemented if BEEP was required?

    Fred: probably not. Andy: so we did the right thing!

    April: are these docs are ready for last call?

    Andy: yes.

    Tomoya Yoshidia: Gives presentation on routing registry. (not a wg item)

    Notes that IRR data is different in that it is duplicated across different organizations. Motivation is to improve the accuracy of the routing registries by using CRISP. Changes from -00: handles routing policy, has no natural root so defined rreg.nro.org(?). Gives example for resolving via RREG.

    Root resolution requires more discussion. Would like this draft to be adopted.

    Ted: worried about "building half a bridge". Basically, concerned about update mechanisms. Obviously they are related. Wonder if community should take this on without taking on the update side as well? How is Yoshida-san keeping his data up to date?

    April: maybe we should collect questions now, and ask on the list.

    Andy: have noticed increased provreg traffic. Does AD think that an EPP extension is appropriate? Scott: could be.

    Ted: not suggesting that this group takes on update side.

    Ed: looks like this data will be sitting with the RIRs & NIRs, if the operators are eager to register their routes with RIRs, then we should have a protocol. But are they?

    Scott: re: provreg -- what has been happening is about moving from PS to Draft Standard. Trying to get feedback on missing features, etc. Haven't gotten any yet. Haven't seen anything that justifies a new WG, but if there really is something, then maybe we should handle both new f

    Larry: should there be a separate root for rreg? Seems like a duplicate effort. Draft still seems very rough.

    William L: routing registries are run in an ad hoc way, we need to consult ISPs to change.

    Kengo: We understand that update is a serious problem, but we were concern about the lack of structure between the routing registries.

    Andre: There are problems injecting new data into routing registries, and IRIS doesn't help with that. routing registries are intrinsically non-hierarchical. At least, have a number of different hierarchies you could follow.

    Cathy: Did you have a change to go the to the operator community?

    Yoshida-san: we can do that.

    April: next steps. One, we accept rreg as a working group item, which requires a charter change, so can't do this right now.

    GGM: a corridor conversation with one of the RPSL authors indicated that an XML schema for Routing info would be "cool".

    Andy: had a similar conversation. An XML version of RPSL would be nice, and can be independent. Ted: is this a prerequisite? Andy: it could be. That would be a good idea for analysis reasons.

    GGM: if it is to be useful, then there should be an xslt that emits RPSL.

    Andy: that is more of a nice to have. If people are still consuming RPSL, what is the point?

    Shane: think rreg might be a waste of time. IRIS works well for areg for us, but RPSL doesn't have the same sort of problems. If there is a structural problem, then that is an administrative problem, not protocol work. We can do this, but don't see it as falling under this group.

    Morishita-san: does deployment questionnaire. Not a CRISP expert, but we have a deployment questionnaire:

    O. who here is a RIR or TLD? [ about 12 people ]

    1. what is current deployment status of CRISP and EPP?

    CRISP [ deploying/testing: 2 people: verisign(tld), .br(tld) plan to introduce: 10]

    EPP [ deployed: vrsn, neustar, .au devel/testing: 2 .se, .ch/.li both for TLD and ENUM, planning 3, no plan: 3? 4? ]

    Andy: dreg2... didn't cover everything that we thought, outright oversights. If we get enough maybe we can start effort of dreg2.

    GGM: is this a major rewrite or minor surgery?

    Andy: mostly just mucking with status codes and result objects, not major surgery.

    Marcos: IRIS versioning means that backwards compatibility is not a great concern.

    Marcos: what does it take to move from PS to draft? open-source?

    Ted: two independent implementations, you do create an interop report that list each feature, and things that don't get interop are probably removed.

    GGM: one is java, one is C++, but between ccTLD and gTLD, there might be different policy decisions that change feature set.

    Ted: also, 6 months have to pass. This group does not have to do the interop and leave it for a future WG. But the interop tests do tell you a lot.


    None received.