2.1.2 Cross Registry Information Service Protocol (crisp)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-01

Chair(s):

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

Internet-Drafts:

  • draft-ietf-crisp-iris-dreg-07.txt
  • draft-ietf-crisp-iris-core-07.txt
  • draft-ietf-crisp-iris-beep-07.txt
  • draft-ietf-crisp-iris-areg-08.txt
  • draft-ietf-crisp-iris-dchk-01.txt
  • draft-ietf-crisp-iris-lwz-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3707 I Cross Registry Internet Service Protocol (CRISP) Requirements

    Current Meeting Report

    Minutes of the CRISP working group
    61st IETF, Washington D.C.
    9 November 2004

    Chairs:
    April Marine
    George Michaelson

    Scribes:
    Kim Davies (minutes)
    George Michaelson (jabber)


    Status of Working Group Documents
    ---------------------------------

    April Marine noted that the working groups three approved documents (core, DREG and BEEP transport) are still working their way through the RFC editor queue, and hopefully will be published as RFCs soon.


    IRIS Address Registry
    ---------------------

    * draft-crisp-iris-areg-08

    Engin Gunduz reported on two draft revisions that had been made since the previous meetings at IETF 60. The summaries would be very similar to updates that had been sent to the mailing list already.

    From -06 to -07:

    - The <name> element and name searchs for networks and ASNs are back, as some considered it necessary.
    - <findASNByNumber> search has been added, with parameters for specificity. As it provides a superset of the AS query, that has been removed. It is very similar to "find network", in that you can search a range.
    - <language> elements have been added to <findOrganizations> and <findContacts> like DREG, which provides for other languages in queries and result sets. There is no word on case sensitivity and it is left to implementors to decide.
    - "closest match" specificity has been removed, covered by the less specific query with a flag for "allowEquivelances" set to true.
    - <beginsWith> and <endsWith> has been added back to <findOrganizations/AutonomousSystemsByName/NetworksByName/Contacts>
    - Added <findByContact> search for ASNs, networks, and organisations by contact. This is in essence a inverse or reverse lookup.
    - Added <findNetworksBySpecificity> search, which helps when multiple networks have the same addresses. Other searches don't work well in working out the parent relationships.
    - The XML syntax was adapted to support these changes
    - <commonName> has been added in, replacing <first/last/middleName> in <contact> result
    - <email> addess to organisations.

    From -07 to -08:

    - A <findNetworksByNameServer> search was added.
    - Normative and Informative references were split up
    - Examples added for specificity searches as an appendix.
    - Fixes in the examples and formal XML statements.

    One key issue that is outstanding is the current reference to a recommended search root, which reads:

    "The client SHOULD start every query from the IRIS server iris.nro.net and follow the referrals to find the authoritative server to actually query."

    There is a concern that the IESG will not be happy with having a specific host hardcoded in the specification.

    George Michaelson stated he felt uncomfortable with having a host in the specification, and would be tempted not to specify the server selection process as a defacto one will likely naturally emerge anyway.

    Scott Hollenbeck echoed this feeling that it didn't seem right to include a hostname.

    Ted Hardie said you could always submit the draft with the reference in, but the IESG may remove it. He said he saw the advantage of having a single root to manage the referral process, but some people may want to set up other services outside this one. He noted that an effort had recently concluded on pulling operational things out of the WHOIS specification, making it a purely technical. He believed it could be appropriate to publish a second document that documented NRO's role in bootstrapping searches, as it doesn't build a dependency into the protocol on a single root.

    Andy Newton pointed out that this is not a mandate for a client to take this approach, that the ultimate resolution method is always left to the client. There is nothing preventing definition of alternative methods, and there has been a substantial discussion on identifying the correct server which arrived at the current wording.

    Shane Kerr supported splitting the document, as did Andrei Robachevsky. Leslie Daigle supported it, and tossed out the possibility of making it an IANA parameter.

    Marcos Sanz stated that some fallback mechanism should be specified in the document.

    Cathy Murphy said she did not mind the split, but pointed to the DREG document which specifies its resolution method in the protocol specification. Andy Newton said it was hard to compare as that is not really the same thing.

    Leslie Newton said the document needed a hostname that was consistent with the expected lifespan of the document. A .arpa address could be percieve as a longer term approach that is consistent with other hardcoded hostnames. Cathy Murphy said that .arpa is for infrastructure related hosts, whereas this is for a directory service. She did not know if the IAB would find that acceptable.

    April Marine suggested that it needed to go to the list, and other than this issue the documents seemed ready to move to WGLC. The room supported this.

    Shane Kerr quickly asked the room whether there was concern about the LLA queries. Tim Christensen noted Andy had asked for a good use case of it on the list and admits he doesn't know of one. As it is not a trivial method to implement, and there is no sense from the user community that it is either useful or dumb, it could be something that could be added at a later date if it is really needed.


    IRIS Domain Availability Check and Lightweight Transport
    --------------------------------------------------------

    * draft-ietf-crisp-iris-dchk-01
    * draft-ietf-crisp-iris-lwz-00

    Andy Newton presented the iris-dchk and iris-lwz drafts, which were new revisions of the iris-dchk draft presented at IETF 60. Previously, iris-dchk contained both a DREG subset that specifically only provided domain status information, as well as a lightweight UDP-based transport. These two new documents split these two functions into distinct documents.

    The LWZ draft is not DCHK specific and can be used as a transport for other IRIS registry types. The draft as it stands however will be substantially rewritten, as after some consideration and implementation experience, the current approach is not ideal. The aim instead is to introduce a lightweight binary wrapper with a small header, rather than the current XML-based wrapper. The problem with using XML is it needs a seperate entry point into the upper layer of the server that is not present with the other transports. The <getProfiles> exchange also proved redundant as S-NAPTR takes care of that.

    The new binary wrapper format would see the XML with a small header, with 1 octet expressing flags that convey status, packet type, compression, and errors; 2 octets for the maximum response packet size the client is willing to accept; and 1 octet for the packet length.

    Ed Lewis questioned whether a 512 byte limit was hardcoded. Andy responded that in previous drafts it was 512, but now the client could say if it knew better.

    Andy said he would publish a new version of the draft quickly with a view to moving it to working group last call.


    Final Comments
    --------------

    April Marine noted that every document will shortly be at Working Group Last Call, except for the newly seperated AREG operational aspects draft, but that would be simple and quickly move to WGLC. She strongly recommended those who had not done so to date to review the drafts during WGLC.

    Slides

    IRIS AREG Draft
    draft-ietf-crisp-iris-dchk and draft-ietf-crisp-iris-lwz