2.1.3 Cross Registry Information Service Protocol (crisp)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-19


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.
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-areg-10.txt
  • draft-ietf-crisp-iris-dchk-02.txt
  • draft-ietf-crisp-iris-lwz-01.txt
  • draft-ietf-crisp-iris-areg-urires-01.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

    Minutes of the CRISP working group
    62nd IETF, Minneapolis USA
    March 2005

    George Michaelson

    Kim Davies

    Status Update

    George Michaelson reported that the group had met three of the four milestones. The only outstanding job was to finish the AREG specification which has been held over to May 2005.

    Four RFCs have been published, and four working group documents are in progress:

    * draft-ietf-crisp-iris-areg-09
    * draft-ietf-crisp-iris-areg-urires-00
    * draft-ietf-crisp-iris-dchk-02
    * draft-ietf-crisp-iris-lwz-01


    Fred Neves reported on the differences in the latest revision -10 of the AREG draft. Included in the changes, <findOrganisztions> was made similar to <findContacts>; Organisational Search Group to provide the same services throughout the document; change of <findNetworkBySpecificity> to <findNetworkByHandle> mentioned in Washington but not included in -10; and for <contact> result added address, city, region, postalCode and country elements.

    It is also proposed to drop the URI resolution draft, instead adding a URI resolution section to the AREG draft. Top-down resolution is still recommended, but the top is left undefined.

    New text for Section 7 will propose including a direct resolution against "areg-iris.arpa", as there needs to be a fixed anchor as opposed to domain names.

    Leslie Daigle suggested some alternate wording on how the IANA request be drafted relating to the areg-iris.arpa registration. Cathy Murphy said that ARIN had some minor rewordings that will be supplied, but that they are not substantive.

    George Michaelson noted that based on discussion, the document should make the May deadline, and the URI resolution draft will be left to die.

    XML Pipelining with Chunks (XPC)

    Andrew Newton reported on his new draft
    (draft-newton-crisp-iris-xpc-00.txt) which provides a new TCP transport for IRIS. Currently defined in RFC is IRIS bindings to BEEP. BEEP was considered useful at the time because it met all the requirements, especially for security. However implementation experience shows it is difficult to implement, especially as BEEP is designed to do many extra things (run over different transports, with multiple channels etc.). It is difficult to write a BEEP library just for use with IRIS, and there is not a rich set of libraries available for BEEP.

    There were two options available - either reuse someting (like with BEEP) or create something new. To reuse something, need to find a protocol that suits - but that may require features in that protocol that are not commonly implemented. If something new is created it needs to be easy to build.

    The first reuse question is "Why not use HTTP?". BCP 56 discusses using HTTP as a substrate, and expresses dire warnings for using it for anything other than web browser. This could be ignored, but may be a political battle not worth fighting.

    HTTP also doesn't support SASL - there is a draft, but hard pressed to find an implementation that supports it. Doesn't really support chunking, which has been defined for HTTP for years, but not many libraries support it.

    This lead to the idea of building something, can be done by a competent programmer in a day or two. The protocol makes room for SASL, the same security layer that BEEP uses, so can be used for different security mechanisms. By design the protocol supports chunking.

    It has something called 'basic auth' built in, using plain text passwords. There is explicit room for SASL, and the draft does define using SSL and TLS in a tunneling mode.

    It is important to note that SASL is being retrofitted. SASL Plain has something called SASL nameprep, that takes something that needs 30 minutes to implement now, and makes it take 2 days. Whilst the nameprep thing isn't actually needed, in the SASL co-chair's words it is a "SHOULD", so if you only have ASCII user names, you dont have to do it. So basic auth may come out.

    On the need for chunking. Why is it important? Essentially when you do octet counting with HTTP or BEEP, you get a whole xml packet, you have to look at content length up front, then you can tell your parser you have all the data. Then to send it back you have to buffer all the data as you need to tell how long it is. There are ways around the first part, but not the second. On an IRIS server, they are not files off the file system where the size is easy to find, this is data generated dynamically so it is hard to do.

    Pipelining cuts up the XML up and sends it in manageable chunks. This results in a smaller footprint and latency as the server is able to divide processing into smaller subsets.

    XPC is very complimentary to the LWZ draft, which is IRIS over UDP. It uses the same XML scheme for versioning etc. All the values in the headers overlap with LWZ, if they have the same meaning it is the same value. Wire format very much like LWZ.

    Brian Tremmel: Have skimmed the draft, how easy would it be to take any XML message request/response protocol and put it on XPC? Is it CRISP specific?

    Andy: Nothing is IRIS and CRISP specific, so it could be used forother messages. The only problem may be the XML trasport scheme's method of versioning: it is not specific to IRIS but it is defined in an IRIS document. The intent was not to design something generic, it was just for this problem, but turns out to be generic.

    Robert Martin-Legene: Could you give an example of what kind of request you would send in chunks?

    Andy: One of the things you would see, is an initial request that says "give me a domain name". The response is here is a domain name and 2 associated nameservers, over the UDP channel. The nameservers may not be in the IRIS response, so 2 more requests may come for those, with 1 nameserver in a chunk, and 1 in another. There are several scenarios with my iris clients, that when you do referral chasing, you get back a set of 1 or 2 objects, if it isn't in the referral section, it can break those up into a manageable chunk and process them.

    IRIS Routing Registry

    Kengo Nagahashi informed the group on investigative work towards implementing a routing registry over IRIS

    Currently query transactions with an IRR is conducted using the WHOIS protocol, which lacks a referral capability - therefore the IRR data is hosted centrally.

    The reason for the interest is in development of Near Real Time Mirroring (NRTM), a mirroring architecture to replicate IRR databases in near time (e.g. 30 minutes). However this requires a referral query mechanism for IRR, and hence a need for RREG. For example, in IRR a routing registry may wish to defer the query to another.

    The initial document is based on the AREG document, and it is hoped to discuss on the mailing list. Would like it to become a working group item.

    Cengiz Alaettinoglu: Does CRISP provide a full real-time mirroring of data?

    George Michaelson: Out of scope, the protocol supports referral and chaining, but as to whether mirrors are done, it is not part of the protocol.

    Andrew Newton: There is a serialisation spec in IRIS to support things like mirroring, escrow, etc.

    ??: The charter would need to be extended to support real-time mirroring in the wg charter. People use this data to configure routers, for that you need every record.

    Cathy Murphy: This brings up another point, what is the resolution method? We just got through figuring out top-down resolution for AREG. There is a natural structure for areg and dreg - what is the resolution method for routing information?

    Kengo: In the draft this is an open issue, what is needed.. this is almost a similar discussion with AREG. Currently in the initial draft, it needs a top down starting resolution point.

    George Michaelson: Two people have expressed views who can't be here. Joao Damas of ISC (RPSL) and Andrei Robachevsky who runs the RIPE Routing Registry. They have made two different observations I should communicate. Joao's concerns were tht the current draft only included information models from AREG, a better approach would be how to represent routing objects in xml syntax. Starting with allocation object set is a disadvantage. He is also concerned that the use of routing registries is really very different to domain or resource management lookup in address registries. Although it is a registry implemented over WHOIS, he felt it is not a given that it should exist in CRISP as well. He didn't say it should not be in crisp, but he said it is not 100% clear as the behaviour set is different.

    Andrei's concern is that this is a tool set for automatic generation of router configs, that toolset uses RPSL to generate an intermediate format, so was concerned there needed to be conformance with that process. Would the tool use XML (may be attractive), the tool (irrtoolset and rpconfig) moved to ISC for maintainance. There is also the question of global coverage, that current registry practices separate management of address and number resources, that people need to assert routes that cover objects that are outside of their control. The work done in routing support includes interesting authorisation behaviours on the input side. It is not a CRISP problem, but is a real one. The rights over the data lie in different spaces, so other dimensions exist to the problem.

    Cengiz: CRISP can encode the routing data, but needs to be extended to include full mirroring and authorisation that is part of the RPSL process. Probably needs specific queries for this type of data. You can't just use AREG to implement it, you need so much more. if you guys took this on, I think it would be a good thing, but there is work that needs charter extension.

    George: Is this a well formed idea, extending out charter? I have no personal view.

    Scott Hollenbeck: Me and Ted have a strong preference for groups finishing their charter before taking new work. If you want to add a missing something though, it can be done. But that is a question for you all to decide.

    George: We need to take this to the list to discuss. If this work continues, the document will need substantial revision. Would like to invite you to take on additional authors from the routing and whois community to help. I am sure someone here can assist. I think we are shepherding this informally until we know more.

    Cathy Murphy: Are you going to be reaching out to the operator forums? I know it was presented at APRICOT. what about NANOG and RIPE meetings?

    Kengo Nagahashi: One target is the RIPE community, APRICOT etc. to involve rir community and routing community. The routing community is the most important for us.

    Andrew Newton: Is there a need for RPSL in XML? Is there resistance from people who may not be in this room? If people are saying it shouldn't be done it helps answer the question. Maybe we should work out if RPSL can be represented as XML, then fit it into IRIS if it fits.

    George Michaelson: It is a valid question - RPSL has fans and enemies. I wouldn't want to say there is opposition, but there are definitive considerations. I am not an XML fanatic. The whole idea of chunking shows issues, but there is such a huge amount of code that can take XML, it is hard to see how router vendors would not want to receive tokenised data in this format. People will probably exploit this if it was done.

    Larry Blunk: I am not sure. I went through the draft, sort of confused, lots of things missing, route objects but not origin AS etc. It looked like the AREG doc with minor mods.

    Andrew Newton: The compelling reason for XML is there are lots of XML parsers, and there are loads of tools. so if you simply took RPSL wrapped in XML it would be useless. so you need to go through the spec and work out how to XML it.


    DCHK and LWZ will be moved to working group last call.


    None received.