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

Chair(s):

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
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.

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)

Internet-Drafts:

  • 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:

    RFCStatusTitle
    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

     draft-ietf-crisp-iris-dchk-03.txt
     draft-ietf-crisp-iris-lwz-04.txt
     draft-ietf-crisp-iris-xpc-02.txt
     draft-ietf-crisp-iris-common-transport-02.txt

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.

	  draft-ietf-crisp-iris-areg-12.txt

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.

GGM: 
	We just need to go through the issue tracker and go the
	mailing list.

Ted: 
	We don't need to do another WGLC for the documents.

Andy: 
	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
       fields.
     
     *  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
       states.

     * 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?

Andy: 
	That is in DNS, but the signature life isn't.

Frederico: 
	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.

Frederico: 
	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?

Andy: 
	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.

Marcos: 
	Not sure this is necessary.  Could be put this under see-also?

Andy: 
	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.
	
Andy: 
	There is no rule writing language.  This is just a identifier
	that names something that is described in a white paper.

Ed: 
	This is a "what is in the registry" protocol, not a business
	rules protocol. 

Marcos: 
	Again, this is freetext and not usable.

Andy: 
	This isn't something that the typical user will do.

Marcos: 
	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.

Andy: 
	Let me send a use case to the mailing list.

Fred: 
	Other non-gtld registries need to look that the status values
	and see if they are sufficient.

 o Progress on RREG
   Kengo Nagahashi 
     draft-kengo-crisp-iris-rreg-02.txt

Nagahashi-san:  rreg presentation. [pls see slides]

Scott Hollenbeck: 
	Do you have an EPP extension for IRR data?

Nagahashi-san: 
	No.

Robert Martin-Legene: 
	Mirroring is probably out of scope for CRISP -- databases have
	solved this problem.  IRIS is just a front-end.

N: 
	CRISP is an alternative to mirroring.  Mirroring guarantees
	local access to the data, which is an advantage.

Andrei: 
	What kind of hierarchy can you describe with the routing data?

N: 
        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.

Ted: 
	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.
Andy: 
	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.

N: 
	BOF may be a good idea.

GGM: 
	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.

    Slides

    DREG2 Presentation