2.1.3 Cross Registry Information Service Protocol (crisp)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-04


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

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>

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 2006  Submit the following drafts for IESG review (Proposed Standards)
Jan 2006  A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS) (Submit to IESG review for Proposed Standard)
Jan 2006  A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service (Submit to IESG review for Proposed Standard)
Jan 2006  A Common Schema for Internet Registry Information Service Transfer Protocols (Submit to IESG review for Proposed Standard)
Jan 2006  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-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

    Minutes for the
    CRISP Working Group Meeting
    IETF 64 -- Vancouver, BC, Canada
    Tuesday, Nov 8, 2005
    minute taker: David Blacka
    chair: George Michaelson
    (co-chair April Marine could not make the meeting, but did
    edit these minutes a bit for format and to summarize a bit more)
     o Update on latest drafts
    Comments from Andy Newton, Ted Hardie, and George follow:
    Andy Newton: 
    	- DCHK has an IANA registration issue for the xml namespace
    	- LWZ has numerous issues
    	- XPC is perfect (actually just can't remember the issues ;).
    	- common-transport has the same xml-namespace IANA issue.
              AFAIK all issues have been addressed.
            The four documents have all been last called.  We just need to
    	rev to fix the current issue and then submit to the IESG.
    Ted Hardie: 
    	AREG has some discusses against it. (FindNetworks, etc.)
         There is a mild XML bug, Alison (Mankin)'s comment about
         publishing the domain name under .arpa. We need to go through the
         discusses and respond to them.
    	We just need to go through the issue tracker and go the
    	mailing list.
    	We don't need to do another WGLC for the documents.
    	Bottom line: I will fix those and send to IESG.
     o DREG2 Plans
    Andy does his presentation on DREG2:
         DREG was the first registry type.  We learned stuff from
    subsequent registry types.  There are new players that had new (minor)
    requirements.  We could probably get this done by the next IETF.
    Nothing is rocket science here.
         The DREG2 schema is done, and in subversion.  What is new:
         *  result.  Looks like a contact with some new
         *  is clarified. (does not return all possible
           variants, only return variants in the registration system).
         *  for finding out registration rules.
         * new status values to be more meaningful to EPP registries.
           Clearer status by splitting statuses that were actual compound
         * status values for non-domain objects, more values for domain.
         * Added "Registration Service Provider".  In addition to
           registrar.  These are third parties in the registration path.
           This isn't a new result object.
         * Signature life for DNSSEC.  Some confusion on this issue, but
           think that there should be only one of these per domain.
         * Controversy on IDNeMail: whether when accepting email
           address/sip address/etc you have to have the nameprep version
           or not.
    Frederico Neves: 
    	Nothing to show the DS record, why?
    	That is in DNS, but the signature life isn't.
    	This is the outside check against the registry.
    Mark Kosters: 
    	I agree with Fred, this is a good thing
    Ed Lewis:
    	With EPP, you are also able to add the DNSKEY record.  You
    	might also want to be able to show the DNSKEY record, too.
    	Lameness check, we need three pieces of data: last time we got
    	a correct answer, status, and last time we checked.
    Marcos Sanz: 
    	What is the listRegistrationRules thing?
    	What are the rules for registering an IDN? Something you can
    	give to the client to allow the client to determine if it can
    	register a domain.  This will be a well-known identifier.
    	Could be an IANA registry.
    	Not sure this is necessary.  Could be put this under see-also?
    	See-also are attached to objects that you already know how to
    	query for.  This is a new thing.
    	This came up specifically in the IDN case.
    John Klensin: 
    	Do you have a language defined for this?  I know of 4
    	different registries that are using 4 different languages to
    	describe variant rules.  I'm concerned that you are putting a
    	hook for something that you don't know how to do.
    	There is no rule writing language.  This is just a identifier
    	that names something that is described in a white paper.
    	This is a "what is in the registry" protocol, not a business
    	rules protocol. 
    	Again, this is freetext and not usable.
    	This isn't something that the typical user will do.
    	When folks want to know this information, I point them to the
    	FAQ on our website.  This isn't the right place to do this.
    John K: 
    	The variant rules will not be sufficient to determine whether
    	a variant could be registered.
    	Let me send a use case to the mailing list.
    	Other non-gtld registries need to look that the status values
    	and see if they are sufficient.
     o Progress on RREG
       Kengo Nagahashi 
    Nagahashi-san:  rreg presentation. [pls see slides]
    Scott Hollenbeck: 
    	Do you have an EPP extension for IRR data?
    Robert Martin-Legene: 
    	Mirroring is probably out of scope for CRISP -- databases have
    	solved this problem.  IRIS is just a front-end.
    	CRISP is an alternative to mirroring.  Mirroring guarantees
    	local access to the data, which is an advantage.
    	What kind of hierarchy can you describe with the routing data?
            Regional, national, local.
    Larry Blunk:
    	We described this in other documents.  We created a hierarchy
    	the started at IANA, but it tied routing registries to address
    	registries and didn't take off.  I think you want to get the
    	heirarchy fixed before you try to address this in crisp.  RPSL
    	already defines a service model, so why start all over again?
    	Also, ISPs may want to mantain their own registries.
    	Recently saw a parallel situation in a different WG.  We
    	reused CRISP in the ECRIT working group, but think it was
    	important to be done in ECRIT because the semantics were (?)
    	best understood in that WG.  The subject of this proposal
    	isn't really suited to this group of people. I offer for you
    	to hold a BOF for something in the routing area, which would
    	give you a greater chance of success.
    	Other IRIS registries have been defined in other WGs, so no
    	requirement to do this here.  But first you need to clarify
    	the issues around how the data moves around.
    	BOF may be a good idea.
    	It doesn't look were are in a position to make a decision to
    	adopt this routing work. We are out of time, so it is looking
    	like we might be able to wrap up in Dallas.
     o WG Next Steps
          Fix current drafts and send to IESG. No need for another last
          call from the working group. RREG work can be spun off into a
          BOF. WG can probably conclude in Dallas.


    DREG2 Presentation