Subject: GA-DIGEST V1 #1614
From: [email-masked] (GA-DIGEST)
To: [email-masked]

GA-DIGEST        Wednesday, February 26 2003        Volume 01 : Number 1614

----------------------------------------------------------------------

Date: Thu, 27 Feb 2003 17:01:54 +0100
From: "J-F C. (Jefsey)  Morfin" <[email-masked]>
Subject: Re: [ga] Requirments for the Crisp (post-whois) service (Was: draft-ietf-crisp-requirements-04.txt

Is that draft part of TIA?

On 10:22 25/02/03, Stephane Bortzmeyer said:

>This draft is the set of requirments for the future Crisp service, the
>successor of the famous whois. The draft talks about many subjects
>which are of great interest for this mailing list (such as privacy
>issues).
>
>The draft is in the state of "Working Group Last Call" which means
>that in a few weeks, it will be sent to the IESG for publication as a
>RFC. So, it is time to comment.
>
>
>
>
>
>Return-Path: <[email-masked]>
>Received: from relay1.nic.fr [192.134.4.17]
>         by localhost with POP3 (fetchmail-5.9.11)
>         for bortzmeyer@localhost (single-drop); Mon, 24 Feb 2003 23:39:41 
> +0100 (CET)
>Received: from relay3.nic.fr ([email-masked] [192.134.4.28])
>         by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h1OMbbZL1056794
>         for <[email-masked]>; Mon, 24 Feb 2003 23:37:37 +0100 (CET)
>Received: by relay3.nic.fr (Postfix, from userid 1018)
>         id ED06A6EF03; Mon, 24 Feb 2003 23:37:36 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>         by relay3.nic.fr (Postfix) with ESMTP id 5ADF66EF3E
>         for <[email-masked]>; Mon, 24 Feb 2003 23:37:00 +0100 (CET)
>Received: from mail.verisignlabs.com (thing.verisignlabs.com [65.201.175.62])
>         by relay3.nic.fr (Postfix) with SMTP id 989C86EF14
>         for <[email-masked]>; Mon, 24 Feb 2003 23:36:54 +0100 (CET)
>Received: (qmail 28882 invoked from network); 24 Feb 2003 22:36:09 -0000
>Received: from unknown (HELO lists.fo.cto.netsol.com) (127.0.0.1)
>   by localhost with SMTP; 24 Feb 2003 22:36:09 -0000
>Delivered-To: [email-masked]
>Received: (qmail 28650 invoked from network); 24 Feb 2003 22:19:55 -0000
>Received: from unknown (HELO zak.ecotroph.net) (216.38.143.123)
>   by lists.fo.cto.netsol.com with SMTP; 24 Feb 2003 22:19:55 -0000
>Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87])
>   (AUTH: LOGIN anewton)
>   by zak.ecotroph.net with esmtp; Mon, 24 Feb 2003 17:19:54 -0500
>Message-ID: <[email-masked]>
>From: Andrew Newton <[email-masked]>
>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
>X-Accept-Language: en-us, en
>Mime-Version: 1.0
>To: [email-masked]
>Subject: [Ietf-not43] draft-ietf-crisp-requirements-04.txt
>Sender: [email-masked]
>Errors-To: [email-masked]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.0.12
>Precedence: bulk
>List-Help: <mailto:[email-masked]?subject=help>
>List-Post: <mailto:[email-masked]>
>List-Subscribe: <http://lists.verisignlabs.com/mailman/listinfo/ietf-not43>,
>         <mailto:[email-masked]?subject=subscribe>
>List-Id: Discussions about Internet infrastructure directory service 
>protocols and requirements that aren't whois. 
><ietf-not43.lists.verisignlabs.com>
>List-Unsubscribe: <http://lists.verisignlabs.com/mailman/listinfo/ietf-not43>,
> 
><mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <http://lists.verisignlabs.com/pipermail/ietf-not43/>
>Date: Mon, 24 Feb 2003 17:30:08 -0500
>X-Virus-Scanned: by AMaViS perl-11-foxtrot
>X-Spam-Status: No, hits=1.9 required=5.0
>         tests=BALANCE_FOR_LONG_20K,BALANCE_FOR_LONG_40K,
>               KNOWN_MAILING_LIST,LINES_OF_YELLING,RCVD_IN_OSIRUSOFT_COM,
>               SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA,
>               X_ACCEPT_LANG,X_OSIRU_SPAM_SRC
>         version=2.43
>X-Spam-Level: *
>Content-Type: multipart/mixed; x-avg-checked=avg-ok-516A5BFD; 
>boundary="=_zak-21817-1046125195-0001-2"
>
>I submitted this today, but considering this is -00 day, the drafts 
>administrator might be a little delayed in getting this out.
>
>So I'm attaching it for early viewing.
>
>-andy
>
>
>
>
>
>Network Working Group                                          A. Newton
>Internet-Draft                                            VeriSign, Inc.
>Expires: August 25, 2003                               February 24, 2003
>
>
>      Cross Registry Internet Service Protocol (CRISP) Requirements
>                     draft-ietf-crisp-requirements-04
>
>Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on August 25, 2003.
>
>Copyright Notice
>
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
>
>Abstract
>
>    Internet registries expose administrative and operational data via
>    varying directory services.  This document defines functional
>    requirements for the directory services of domain registries and the
>    common base requirements for extending the use of these services for
>    other types of Internet registries.
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                 [Page 1]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>Table of Contents
>
>    1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   4
>    1.1    Background . . . . . . . . . . . . . . . . . . . . . . . .   4
>    1.2    Requirements Scope . . . . . . . . . . . . . . . . . . . .   4
>    1.3    Requirements Specification . . . . . . . . . . . . . . . .   4
>    2.     Internet Registry Communities  . . . . . . . . . . . . . .   6
>    2.1    Domain Name System Registries  . . . . . . . . . . . . . .   6
>    2.1.1  Domain Registries  . . . . . . . . . . . . . . . . . . . .   6
>    2.1.2  Domain Registrars  . . . . . . . . . . . . . . . . . . . .   6
>    2.2    Other Registries . . . . . . . . . . . . . . . . . . . . .   7
>    2.2.1  Regional Internet Registries . . . . . . . . . . . . . . .   7
>    2.2.2  Local Internet Registries  . . . . . . . . . . . . . . . .   7
>    2.2.3  Internet Routing Registries  . . . . . . . . . . . . . . .   7
>    2.2.4  Incident Coordination Contact Registries . . . . . . . . .   7
>    2.2.5  Network Edge Resource Registries . . . . . . . . . . . . .   8
>    2.3    Implementers . . . . . . . . . . . . . . . . . . . . . . .   8
>    2.4    End Users  . . . . . . . . . . . . . . . . . . . . . . . .   8
>    2.4.1  Service Providers and Network Operators  . . . . . . . . .   8
>    2.4.2  Intellectual Property Holders  . . . . . . . . . . . . . .   8
>    2.4.3  Law Enforcement  . . . . . . . . . . . . . . . . . . . . .   9
>    2.4.4  Certificate Authorities  . . . . . . . . . . . . . . . . .   9
>    2.4.5  DNS Users  . . . . . . . . . . . . . . . . . . . . . . . .   9
>    2.4.6  Domain Registrants . . . . . . . . . . . . . . . . . . . .   9
>    2.4.7  Abusive Users  . . . . . . . . . . . . . . . . . . . . . .   9
>    2.5    Other Actors . . . . . . . . . . . . . . . . . . . . . . .   9
>    3.     Functional Requirements  . . . . . . . . . . . . . . . . .  10
>    3.1    Base Functions . . . . . . . . . . . . . . . . . . . . . .  10
>    3.1.1  Mining Prevention  . . . . . . . . . . . . . . . . . . . .  10
>    3.1.2  Minimal Technical Reinvention  . . . . . . . . . . . . . .  10
>    3.1.3  Standard and Extensible Schemas  . . . . . . . . . . . . .  10
>    3.1.4  Level of Access  . . . . . . . . . . . . . . . . . . . . .  11
>    3.1.5  Client Processing  . . . . . . . . . . . . . . . . . . . .  12
>    3.1.6  Entity Referencing . . . . . . . . . . . . . . . . . . . .  12
>    3.1.7  Decentralization . . . . . . . . . . . . . . . . . . . . .  12
>    3.1.8  Query of Access Permission . . . . . . . . . . . . . . . .  12
>    3.1.9  Authentication Distribution  . . . . . . . . . . . . . . .  12
>    3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . .  13
>    3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . .  13
>    3.1.12 Protocol and Schema Versioning . . . . . . . . . . . . . .  14
>    3.1.13 Relay Bag  . . . . . . . . . . . . . . . . . . . . . . . .  14
>    3.2    Domain Specific Functions  . . . . . . . . . . . . . . . .  14
>    3.2.1  Lookups  . . . . . . . . . . . . . . . . . . . . . . . . .  15
>    3.2.2  Searches . . . . . . . . . . . . . . . . . . . . . . . . .  15
>    3.2.3  Information Sets . . . . . . . . . . . . . . . . . . . . .  16
>    3.2.4  Serialization Support  . . . . . . . . . . . . . . . . . .  17
>    3.2.5  Result Set Limits  . . . . . . . . . . . . . . . . . . . .  17
>    3.2.6  DNS Delegation Referencing . . . . . . . . . . . . . . . .  18
>
>
>
>Newton                  Expires August 25, 2003                 [Page 2]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    3.2.7  Distribution for Domain Registry Types . . . . . . . . . .  18
>    3.2.8  Data Omission  . . . . . . . . . . . . . . . . . . . . . .  19
>    3.2.9  Internationalization . . . . . . . . . . . . . . . . . . .  19
>    4.     Feature Requirements . . . . . . . . . . . . . . . . . . .  21
>    4.1    Client Authentication  . . . . . . . . . . . . . . . . . .  21
>    4.2    Referrals  . . . . . . . . . . . . . . . . . . . . . . . .  21
>    4.3    Common Referral Mechanism  . . . . . . . . . . . . . . . .  21
>    4.4    Structured Queries and Responses . . . . . . . . . . . . .  21
>    4.5    Existing Schema Language . . . . . . . . . . . . . . . . .  21
>    4.6    Defined Schemas  . . . . . . . . . . . . . . . . . . . . .  21
>    5.     Internationalization Considerations  . . . . . . . . . . .  22
>    6.     IANA Considerations  . . . . . . . . . . . . . . . . . . .  23
>    7.     Security Considerations  . . . . . . . . . . . . . . . . .  24
>           Normative References . . . . . . . . . . . . . . . . . . .  25
>           Informative References . . . . . . . . . . . . . . . . . .  26
>           Author's Address . . . . . . . . . . . . . . . . . . . . .  26
>    A.     Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  27
>    B.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  28
>    B.1    Forums . . . . . . . . . . . . . . . . . . . . . . . . . .  28
>    B.2    Working Group  . . . . . . . . . . . . . . . . . . . . . .  28
>    B.3    Contributions  . . . . . . . . . . . . . . . . . . . . . .  29
>           Intellectual Property and Copyright Statements . . . . . .  30
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                 [Page 3]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>1. Introduction
>
>1.1 Background
>
>    The expansion and growth of the Internet has seen the registry
>    function of a traditionally centralized and managed Network
>    Information Center become the responsibility of various autonomous,
>    functionally disparate, and globally distributed Internet registries.
>    With the broadening number of Internet registries, the uses of their
>    administrative directory services have expanded from the original and
>    traditional use of the whois [6] protocol to include the use of whois
>    outside the scope of its specification, formal and informal
>    definitions of syntax, undocumented security mechanisms, the use of
>    other protocols, such as rwhois [5], to fulfill other needs, and
>    proposals for the use of other technologies such as LDAP [4] and XML.
>
>1.2 Requirements Scope
>
>    The scope of the requirements captured in this document relate to the
>    directory services of Internet registries and their related
>    communities (Section 2.3,Section 2.4, and Section 2.5).  This scoping
>    specifically targets the requirements of domain name registries
>    (Section 2.1) while acknowledging extensibility needs for possible
>    future support of the requirements for other registry (Section 2.2)
>    types.  The requirements are of both the current use of these
>    directory services and the desired functionality based on input from
>    relevant forums (Appendix B.1).  These requirements are not specific
>    to any protocol.  Terms used in the definition of requirements in
>    this document may be found in the glossary (Appendix A).
>
>    The scope of the requirements in this document are also restricted to
>    access of data from Internet registries.  Requirements for
>    modification, addition, or provisioning of data in Internet
>    registries are out of scope.
>
>1.3 Requirements Specification
>
>    The requirements captured in this document are for the purpose of
>    designing technical specifications.  The words used in this document
>    for compliance with RFC2119 [3] do not reference or specify policy
>    and speak only to the capabilities in the derived technology.  For
>    instance, this document may say that the protocol "MUST" support
>    certain features.  An actual service operator is always free to
>    disable it (and then to return an error such as "permission denied".)
>
>    Requirements in this document specifying the capabilities of the
>    protocol required for proper interaction between a client and a
>    server will be specified with the "MUST/SHOULD" language of RFC2119
>
>
>
>Newton                  Expires August 25, 2003                 [Page 4]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    [3].  This document also contains language relating to the
>    interaction of a client with multiple servers to form a coherent,
>    cross-network service.  Such service requirements will not be
>    described using RFC2119 language.
>
>    While individual servers/service operators may not support all
>    features that the protocol can support, they must respect the
>    semantics of the protocol queries and responses.  For example, a
>    server should not return referrals if it does not have referent data.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                 [Page 5]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>2. Internet Registry Communities
>
>    The Internet registries are composed of various communities which
>    provide scope for the requirements in this document.  These
>    communities can be generalized into the following categories:
>    registries, registrars, implementers, end-users, and other actors.
>
>2.1 Domain Name System Registries
>
>2.1.1 Domain Registries
>
>    Domain registries are responsible for the registration of domains for
>    use with DNS [1] and forward lookups (i.e.  does not include the
>    IN-ADDR.ARPA or IP6.ARPA domains).  These registries have typically
>    served two main domain functions: as the registry for a gTLD or as a
>    registry for a ccTLD.  In some instances, one entity will operate
>    multiple TLD's, both of the gTLD and ccTLD type.  A gTLD or ccTLD
>    domain registry operator may be a governmental entity,
>    non-governmental, non-commercial entity, or a commercial entity.
>
>    Some ccTLD's have second-level domain registrations similar in nature
>    to gTLD's or have distinctly separate entities operating second-level
>    domain registries similar in nature to gTLD's within the ccTLD.
>
>    Domain registries usually follow one of two models for conducting
>    registrations of domains.  The "thick" model is the more traditional
>    model.  In a "thick" domain registry, the registry contains both the
>    operational data for the domain and the contact or social data
>    (Appendix A) for the domain.  In this model, the registry is
>    typically the interface to the domain registrant but may also
>    interface with the domain registrant through domain registrars.  The
>    "thin" model domain registry contains only operational data for
>    domains.  In the "thin" model, contact or social data for the domain
>    are maintained by a domain registrar.
>
>    Domain registries not described in this section (Section 2.1.1) are
>    not the subject of this document and may have requirements that are
>    out of scope for this subject matter.
>
>2.1.2 Domain Registrars
>
>    Domain registrars accept domain registrations from registrants on
>    behalf of domain registries, both "thick" and "thin".  In a "thin"
>    model registry/registrar system, a domain registrar maintains the
>    contact and social data of a domain while the registry maintains the
>    operational data of a domain.  In a "thick" model registry/registrar
>    system, a domain registrar passes both the operational data and
>    contact data to the registry.  Domain registrars may register a
>
>
>
>Newton                  Expires August 25, 2003                 [Page 6]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    domain on behalf of a registrant in more than one domain registry.
>
>2.2 Other Registries
>
>2.2.1 Regional Internet Registries
>
>    Regional Internet Registries (RIR's) administer the allocation of IP
>    address space and autonomous system numbers.  Each RIR serves a
>    specific geographic region, and collectively they service the entire
>    Internet.  Each RIR is a membership-based, non-profit organization
>    that facilitates and implements global addressing policy based on the
>    direction of their regional community.
>
>2.2.2 Local Internet Registries
>
>    Local Internet Registries (LIR's) and National Internet Registries
>    (NIR's) are sub-registries of RIR's and coordinate the same functions
>    of the RIR's for smaller, more specific geographic regions, sovereign
>    nations, and localities.
>
>2.2.3 Internet Routing Registries
>
>    Internet Routing Registries are routing policy databases.  Their
>    purpose is to provide information helpful in administering Internet
>    routers.  Frequently, the syntax and contents are defined by RPSL
>    [7].
>
>    IRR's are operated by academic, commercial, governmental, and other
>    types of organizations, including several of the RIR's.  The contents
>    of the databases vary and reflect the needs of the users directly
>    served (e.g.  an ISP may look up route entries added by their
>    customers to decide whether to accept specific route advertisements
>    they receive).
>
>    Unlike RIR and domain registry data, IRR data is often duplicated
>    between separate organizations.  The IRR data has the unique
>    characteristics of being largely available through other sources
>    (i.e.  it is advertised by the Internet routing protocols) and most
>    often having a common data format, RPSL.
>
>2.2.4 Incident Coordination Contact Registries
>
>    Incident coordination contact registries allow operators of network
>    resources such as network infrastructure, network names, or network
>    services to register contact information for the purpose of providing
>    a means of incident notification.  Using this type of registry, an
>    operators of network resources are provided information for
>    contacting the operator of another network resource from which an
>
>
>
>Newton                  Expires August 25, 2003                 [Page 7]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    incident may be occurring.
>
>2.2.5 Network Edge Resource Registries
>
>    Network edge resource registries provide specific information about
>    "edge" resources.  They are administered by the operators of the
>    resources.  Examples of such registries are rwhois [5] servers
>    operated by networks to describe the assignment of address space
>    allocated by RIR's or LIR's and whois [6] servers operated by
>    networks to specifically announce routing policy of that network.
>
>2.3 Implementers
>
>    Implementers of client software are often either affiliated with
>    large network operators, registry operators, or commercial entities
>    offering value-added services, or are general citizens of the
>    Internet.  Much of the client software for use with the directory
>    services of Internet registries is either freely available, open
>    source, or both, or available as a service.  Implementers of server
>    software are often affiliated with operators or commercial entities
>    specializing in the out-sourcing of development for Internet
>    registries.
>
>2.4 End Users
>
>2.4.1 Service Providers and Network Operators
>
>    Service providers and network operators provide connectivity,
>    routing, and naming services to many other entities, some commercial
>    and some non-commercial, both large and small.  Their operational and
>    administrative staff often interact with Internet registries on
>    behalf of other end-users.  Service providers and network operators
>    interact with all of the Internet registry operators outlined in this
>    document on a frequent and consistent basis.  For example, network
>    operators use the directory services of Internet registries to
>    determine contact information for network resources that have
>    technical problems.
>
>2.4.2 Intellectual Property Holders
>
>    A number of parties, such as trademark, service mark and intellectual
>    property holders, individuals, governments and other geopolitical
>    entities, have some legal rights on certain alphanumeric strings.
>    They use the directory services of Internet registries, mostly domain
>    registries and registrars, for purposes of maintaining and defending
>    claims to domain names consistent with applicable laws and
>    regulations.
>
>
>
>
>Newton                  Expires August 25, 2003                 [Page 8]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>2.4.3 Law Enforcement
>
>    Law enforcement agencies use the directory services of Internet
>    registries to find information used to carry out the enforcement of
>    laws within their jurisdictions.
>
>2.4.4 Certificate Authorities
>
>    Certificate authorities use the directory services of Internet
>    registries as part of their verification process when issuing
>    certificates for Internet named hosts.
>
>2.4.5 DNS Users
>
>    Users of the Internet have client software that resolves domain names
>    to IP addresses.  Often when trouble occurs in the resolution process
>    of DNS, these users trouble shoot system problems with the aid of
>    information from the directory services of Internet registries.
>
>2.4.6 Domain Registrants
>
>    Entities given authority over a domain via purchase, lease, or grant
>    from a domain registry, either directly or via the services of a
>    domain registrar.
>
>2.4.7 Abusive Users
>
>    The administrative directory services of Internet registries are
>    often the target of practices by abusive users.  Using information
>    obtained from Internet registries, abusive users undertake certain
>    activities that are counter to the acceptable use of the information
>    as intended by a registry, registrar, or registrant.  Many times,
>    these practices violate law in the jurisdiction of the user,
>    registry, registrar, or registrant.  One example is the use of
>    Internet registry information for the use of sending unsolicited bulk
>    or commercial email.
>
>2.5 Other Actors
>
>    Requirements must also consider the positions and policies of other
>    actors on the use of Internet registry directory services.  These
>    actors include governments, non-governmental policy-setting bodies,
>    and other non-governmental organizations.
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                 [Page 9]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>3. Functional Requirements
>
>    Functional requirements describe an overall need or process for which
>    the directory service is used by an Internet registry to fulfill its
>    obligations to provide access to its respective customers, members,
>    or other constituents.  This section describes requirements in the
>    manner specified in Section 1.3.
>
>3.1 Base Functions
>
>    This section describes basic directory service protocol requirements
>    for domain name (Section 2.1) and other (Section 2.2) registries.
>    Additional requirements, specific to domain registries, are described
>    in Domain Specific Functions (Section 3.2).
>
>3.1.1 Mining Prevention
>
>    In order to prevent the inappropriate acquisition of data from an
>    Internet registry's directory service, many servers will limit the
>    amount of data that may be returned in a fixed time period from a
>    server to a client.  This will most likely be especially true for
>    anonymous access uses (see Section 3.1.4).
>
>    The limits placed on differing types of data or applied depending
>    upon access status will most likely differ from server to server
>    based on policy and need.  Support for varying service models in the
>    effort to limit data and prevent data mining may or may not have a
>    direct impact on the client-to-server protocol.
>
>    Section 3.2.5 also contains protocol requirements which are relevant
>    to client/server interaction in certain domain registry service
>    models.
>
>3.1.2 Minimal Technical Reinvention
>
>    The protocol MUST NOT employ unique technology solutions for all
>    aspects and layers above the network and transport layers and SHOULD
>    make use of existing technology standards where applicable.  The
>    protocol MUST employ the use of network and transport layer standards
>    as defined by the Internet Engineering Task Force.  The protocol MUST
>    define one or more transport mechanisms for mandatory implementation.
>
>3.1.3 Standard and Extensible Schemas
>
>3.1.3.1 Protocol Requirement
>
>    The protocol MUST contain standard schemas for the exchange of data
>    needed to implement the functionality in this document.  In addition,
>
>
>
>Newton                  Expires August 25, 2003                [Page 10]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    there MUST be a means to allow the use of schemas not defined by the
>    needs of this document.  Both types of schemas MUST use the same
>    schema language.  The schemas MUST be able to express data elements
>    with identifying tags for the purpose of localization of the meaning
>    of the identifying tags.
>
>3.1.3.2 Service Description
>
>    The client-to-server protocol must define a standard set of data
>    structures or schemas to be used when exchanging information.  It
>    must also poses the ability to allow for the use of newer data
>    structures that are currently nor foreseen by this specification.  In
>    both cases, the description and specification of both types of data
>    structures or schemas must be done in the same way (i.e.  the same
>    schema language).
>
>    The schemas must also be capable of "tagging" data with a unique
>    identifier.  This identifier can then be used to localize the name of
>    that type of data.  For instance, a piece of data may have the value
>    "Bob" and its type identified with the number "5.1".  Client software
>    could use this to display "Name: Bob" in an English locale or
>    "Nombre: Bob" in a Spanish locale.
>
>3.1.4 Level of Access
>
>3.1.4.1 Protocol Requirement
>
>    The protocol MUST NOT prohibit an operator from granularly assigning
>    multiple types of access to data according to the policies of the
>    operator.  The protocol MUST provide an authentication mechanism and
>    MUST NOT prohibit an operator from granting types of access based on
>    authentication.
>
>    The protocol MUST provide an anonymous access mechanism that may be
>    turned on or off based on the policy of an operator.
>
>3.1.4.2 Service Description
>
>    Server operators will offer varying degrees of access depending on
>    policy and need.  The following are some examples:
>
>    o  users will be allowed access only to data for which they have a
>       relationship
>
>    o  unauthenticated or anonymous access status may not yield any
>       contact information
>
>    o  full access may be granted to a special group of authenticated
>
>
>
>Newton                  Expires August 25, 2003                [Page 11]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>       users
>
>    The types of access allowed by a server will most likely vary from
>    one operator to the next.
>
>3.1.5 Client Processing
>
>    The protocol MUST be capable of allowing machine parsable requests
>    and responses.
>
>3.1.6 Entity Referencing
>
>    There MUST be a mechanism for an entity contained within a server to
>    be referenced uniquely by an entry in another server.
>
>3.1.7 Decentralization
>
>3.1.7.1 Protocol Requirement
>
>    The protocol MUST NOT require the aggregation of data to a central
>    repository, server, or entity.  The protocol MUST NOT require
>    aggregation of data indexes or hints to a central repository, server,
>    or entity.
>
>3.1.7.2 Service Description
>
>    Some server operators may have a need to coordinate service in a mesh
>    or some other framework with other server operators.  However, the
>    ability to operate a CRISP compliant server must not require this.
>
>3.1.8 Query of Access Permission
>
>3.1.8.1 Protocol Requirement
>
>    The protocol MUST provide a mechanism allowing a client to determine
>    if a query will be denied before the query is submitted according to
>    the appropriate policies of the operator.
>
>3.1.8.2 Service Description
>
>    Because usage scenarios will differ depending on both policy and type
>    of service, some server operators may want to provide the ability for
>    a client to predetermine its ability to retrieve data from a query.
>    However, some operators will not allow this for security reasons,
>    policy restrictions, or other matters.
>
>3.1.9 Authentication Distribution
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 12]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>3.1.9.1 Protocol Requirement
>
>    The protocol MUST NOT require any Internet registry to participate in
>    any authentication system.  The protocol MUST NOT prohibit the
>    participation by an Internet registry in federated, distributed
>    authentication systems.
>
>3.1.9.2 Service Description
>
>    Some server operators may have a need to delegate authentication to
>    another party or participate in a system where authentication
>    information is distributed.  However, the ability to operate a CRISP
>    compliant server must not require this.
>
>3.1.10 Base Error Responses
>
>    The protocol MUST be capable of returning the following types of
>    non-result or error responses to all lookups and searches:
>
>    o  permission denied - a response indicating that the search or
>       lookup has failed due to insufficient authorization.
>
>    o  not found - the desired results do not exist.
>
>    o  insufficient resources - the search or lookup requires resources
>       that cannot be allocated.
>
>
>3.1.11 Query Distribution
>
>3.1.11.1 Protocol Requirement
>
>    The protocol MUST NOT prohibit a server from participating in a query
>    distribution system.
>
>3.1.11.2 Service Description
>
>    For lookups and searches requiring distribution of queries, the
>    client must be allowed to distribute these queries among the
>    participants in an established mesh of server operators.  It is not a
>    requirement that the protocol enable the discovery of servers, but
>    cooperating servers should be able to intelligently handle
>    distribution with its established mesh.  Individual server operators
>    will respond to all queries received according to their policies for
>    authentication, privacy, and performance.
>
>    However, the ability to operate a CRISP compliant server must not
>    require the participation in any query distribution system.
>
>
>
>Newton                  Expires August 25, 2003                [Page 13]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>3.1.12 Protocol and Schema Versioning
>
>3.1.12.1 Protocol Requirements
>
>    The protocol MUST provide a means by which the end-systems can either
>    identify or negotiate over the protocol version to be used for any
>    query or set of queries.
>
>    All resource-specific schema MUST provide a version identifier
>    attribute which uniquely and unambiguously identifies the version of
>    the schema being returned in the answer set to a query.
>
>3.1.12.2 Service Description
>
>    The service should allow end-systems using different protocol
>    versions to fallback to a mutually supported protocol version.  If
>    this is not possible, the service must provide a meaningful error
>    which indicates that this is the specific case.
>
>    The service must suggest negotiation and/or recovery mechanisms for
>    clients to use when an unknown schema version is received.
>
>3.1.13 Relay Bag
>
>3.1.13.1 Protocol Requirement
>
>    When issuing a referral, the protocol MUST be capable of supplying a
>    relay bag from the server to the client, and the protocol MUST be
>    capable of allowing the client to submit this relay bag with a query
>    to the referred server.  The use of the relay bag MUST be OPTIONAL.
>    The protocol MUST NOT make any assumptions regarding the contents of
>    the relay bag, but the relay bag MUST be described using the schema
>    language of the protocol.
>
>3.1.13.2 Service Description
>
>    In some models where service coordination among participating server
>    operators is utilized, there might be needs to allow a referring
>    server to pass operator-to-operator coordination data along with the
>    referral to the referent server.  Such needs might be auditing or
>    tracking.  This feature requirement allows a server to pass to the
>    client a flexible container of unspecified data ("bag") that the
>    client should pass to the referent server.  The bag has no meaning to
>    the client.
>
>3.2 Domain Specific Functions
>
>    These functions describe requirements specifically needed by domain
>
>
>
>Newton                  Expires August 25, 2003                [Page 14]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    registries (Section 2.1.1) and domain registrars (Section 2.1.2).
>    Requirements specific to other registries (Section 2.2) MUST be
>    specified separately.  No compliant server operator is required to
>    support the functions required by every registry type.
>
>3.2.1 Lookups
>
>3.2.1.1 Protocol Requirement
>
>    The protocol MUST contain the following lookup functions:
>
>    1.  Contact lookup given a unique reference to a contact of a
>        resource.
>
>    2.  Nameserver lookup given a fully-qualified host name or IP address
>        of a nameserver.
>
>    3.  Domain lookup given a fully-qualified domain name.
>
>    See Section 3.2.3 for the requirements regarding the expected return
>    values.
>
>3.2.1.2 Service Description
>
>    These lookups are all single index queries and should produce zero or
>    only one result.
>
>    Depending on the policy and need of an Internet registry, a server
>    operator may not allow all or any of these lookups to return part or
>    all of the information.  See Section 3.2.3.
>
>3.2.2 Searches
>
>3.2.2.1 Protocol Requirement
>
>    The protocol MUST contain the following search functions:
>
>    1.  Domain name search given an exact match or reasonable subset of a
>        name.  This search SHOULD allow for parameters and qualifiers
>        designed to allow better matching of internationalized domain
>        names and SHOULD allow for both exact and partial matching within
>        the limits of internationalized domain names.  This search SHOULD
>        NOT require special transformations of internationalized domain
>        names to accommodate this search.  This search MUST provide a
>        means to narrow the search by names delegated under a particular
>        TLD.
>
>    2.  Domain registrant search by either exact name or partial name
>
>
>
>Newton                  Expires August 25, 2003                [Page 15]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>        match with the ability to narrow the search to registrants of a
>        particular TLD.
>
>    3.  Domains hosted by a nameserver given the fully-qualified host
>        name or IP address of a nameserver.
>
>    See Section 3.2.3 for the requirements regarding the expected return
>    values.
>
>3.2.2.2 Service Description
>
>    Depending on the policy and need of an Internet registry, a server
>    operator may not allow all or any of these searches to return part or
>    all of the information.  See Section 3.1.4.  Access to information
>    resulting from these searches may also be limited, depending on
>    policy, by quantity.  Section 3.2.5 describes these types of
>    restrictions.
>
>    Some Internet registries may also be participating in a query
>    distribution system.  See Section 3.1.11.
>
>3.2.3 Information Sets
>
>3.2.3.1 Protocol Requirements
>
>    The data sets for contacts, nameservers, and domains MUST be able to
>    express and represent the attributes and allowable values of
>    registration requests in domain registration and provisioning
>    protocols.
>
>    The schema MUST be capable of expressing the following information
>    for domains:
>
>    o  activation status
>
>    o  registrant
>
>    o  nameservers
>
>    o  technical, billing or other contacts
>
>    o  registry delegating the domain
>
>    o  registrar for the domain
>
>    The data set for domains MUST be able to express arbitrary textual
>    information for extensions on an individual operator basis.  Examples
>    of such information are license agreements, authorized use policies,
>
>
>
>Newton                  Expires August 25, 2003                [Page 16]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    extended status notifications, marketing/for sale notices, and URI
>    references to other sources.
>
>3.2.3.2 Service Description
>
>    It is not expected that every Internet registry supply all of the
>    information spelled out above, however the schemas employed by the
>    protocol must be capable of expressing this information should a
>    registry need to provide it.
>
>    The following sections describe requirements relative to the use of
>    schemas with respect to individual registry need and policy:
>
>    o  Section 3.2.8
>
>    o  Section 3.2.5
>
>    o  Section 3.1.4
>
>    o  Section 3.1.1
>
>
>3.2.4 Serialization Support
>
>    The schemas used by the protocol SHOULD be capable of off-line
>    serialization
>
>    Off-line serialization allows for implementation independent
>    operations such as backup and recovery, load-balancing, etc.  This
>    MAY also make possible, in whole or in part, data escrow capabilities
>    and other usages, however such usages are out of the scope of this
>    document.
>
>3.2.5 Result Set Limits
>
>3.2.5.1 Protocol Requirement
>
>    The protocol MUST contain a feature, used at the discretion of a
>    server operator, to allow a server to express to a client a limit on
>    the number of results from searches and lookups.  When returning
>    result sets, the protocol MUST be able to make the following
>    distinctions:
>
>    1.  an empty result set.
>
>    2.  a result set truncated for the purpose of improving performance
>        bottlenecks.
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 17]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    3.  a result set truncated to comply with Section 3.1.1
>
>
>3.2.5.2 Service Description
>
>    Client software will operate more usefully if it can understand
>    reasons for the truncation of result sets.  Of course, some Internet
>    registries may not be able to expose their policies for the limiting
>    of result sets, but, when it is possible, clients will have a better
>    operational view.  This may eliminate re-queries and other repeated
>    actions that are not desirable.
>
>3.2.6 DNS Delegation Referencing
>
>3.2.6.1 Protocol Requirement
>
>    The protocol MUST use the delegation authority model available in DNS
>    [1] as the primary means for determining the authoritative source for
>    information regarding domains or any other objects when applicable.
>
>3.2.6.2 Service Description
>
>    The intent of this requirement is to have clients use the DNS
>    delegation model to find servers authoritative for resources instead
>    of using a master or central server containing pointer information.
>    In other words, when a resource is naturally mapped by DNS, the
>    desired behavior is to consult the DNS to find an authoritative
>    server containing information about that resource.  Using
>    'example.com', the authoritative server for information about
>    example.com according to the registrant of that domain may be found
>    by querying the DNS zone for example.com.  To find the registry
>    information for example.com, the DNS zone for com should be queried.
>
>    There are cases where resources will not naturally map into the DNS
>    delegation hierarchy.  This requirement is not meant to force such a
>    mapping.
>
>3.2.7 Distribution for Domain Registry Types
>
>3.2.7.1 Protocol Requirement
>
>    The protocol MUST NOT prohibit the distribution of data to exclude
>    any of the registry/registrar models stated in Section 2.1.1.  The
>    protocol MUST be capable of expressing referrals and entity
>    references between the various models described in Section 2.1.1.
>
>3.2.7.2 Service Description
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 18]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    Depending on the domain registry/registrar model in use, technical
>    data for a domain may only reside in one server while contact data
>    for the same domain may only reside in a server operated by a
>    separate entity.  However, in many uses, this is not the situation.
>    Therefore, the service must accommodate for the various registration
>    distribution models of domain registry types described in Section
>    2.1.1 while complying with Section 3.1.7.
>
>3.2.8 Data Omission
>
>3.2.8.1 Protocol Requirement
>
>    When a value in an answer to a query cannot be given due to policy
>    constraints, the protocol MUST be capable of expressing the value in
>    one of three ways:
>
>    1.  complete omission of the value without explanation
>
>    2.  an indication that the value cannot be given due to insufficient
>        authorization
>
>    3.  an indication that the value cannot be given due to privacy
>        constraints regardless of authorization status
>
>    The protocol MAY define other values for this purpose, but MUST
>    define values defined above at a minimum.
>
>3.2.8.2 Service Description
>
>    Internet registries will have varying constraints regarding their
>    ability to expose certain types of data, usually social information.
>    Server operators must have the ability to accommodate this need while
>    client software will be more useful when provided with proper
>    explanations.  Therefore, depending on policy, a server operator has
>    a choice between not returning the data at all, signaling a
>    permission error, or indicating a privacy constraint.
>
>3.2.9 Internationalization
>
>    The schema defining domain related resources MUST conform to RFC 2277
>    [2] regarding textual data.  In particular, the schema MUST be able
>    to indicate the charset and language in use with unstructured textual
>    data.
>
>    The protocol MUST be able to support multiple representations of
>    contact data, with these representations complying with the
>    requirements in Section 3.2.3.  The protocol MUST be able to provide
>    contact data in UTF-8 and SHOULD be able to provide contact data in
>
>
>
>Newton                  Expires August 25, 2003                [Page 19]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    US-ASCII, other character sets, and capable of specifying the
>    language of the data.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 20]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>4. Feature Requirements
>
>    Feature requirements describe the perceived need derived from the
>    functional requirements for specific technical criteria of the
>    directory service.  This section describes requirements in the manner
>    specified in Section 1.3.
>
>4.1 Client Authentication
>
>    Entities accessing the service (users) MUST be provided a mechanism
>    for passing credentials to a server for the purpose of
>    authentication.  The protocol MUST provide a mechanism capable of
>    employing many authentication types and capable of extension for
>    future authentication types.
>
>4.2 Referrals
>
>    To distribute queries for search continuations and to issue entity
>    references, the protocol MUST provide a referral mechanism.
>
>4.3 Common Referral Mechanism
>
>    To distribute queries for search continuations and to issue entity
>    references, the protocol MUST define a common referral scheme and
>    syntax.
>
>4.4 Structured Queries and Responses
>
>    To provide for machine consumption as well as human consumption, the
>    protocol MUST employ structured queries and responses.
>
>4.5 Existing Schema Language
>
>    To provide structured queries and responses and allow for minimal
>    technological reinvention, the protocol MUST employ a pre-existing
>    schema language.
>
>4.6 Defined Schemas
>
>    To provide for machine consumption as well as human consumption, the
>    protocol MUST define schemas for use by the structured queries and
>    responses.
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 21]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>5. Internationalization Considerations
>
>    Requirements defined in this document MUST consider the best
>    practices spelled out in [2].
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 22]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>6. IANA Considerations
>
>    IANA consideration for any service meeting these requirements will
>    depend upon the technologies chosen and MUST be specified by any
>    document describing such a service.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 23]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>7. Security Considerations
>
>    This document contains requirements for the validation of
>    authenticated entities and the access of authenticated entities
>    compared with the access of non-authenticated entities.  This
>    document does not define the mechanism for validation of
>    authenticated entities.  Requirements defined in this document MUST
>    allow for the implementation of this mechanism according best common
>    practices.
>
>    The requirement in Section 3.1.4 must be weighed against other
>    requirements specifying search or lookup capabilities.
>
>    This document contains requirements for referrals and entity
>    references.  Client implementations based on these requirements
>    SHOULD take proper care in the safe-guarding of credential
>    information when resolving referrals or entity references according
>    to best common practices.
>
>    This document contains requirements for the distribution of queries
>    among a mesh of participating service providers.  Protocols proposed
>    to meet these requirements must be able to protect against the use of
>    that distribution system as a vector of distributed denial of service
>    attacks or unauthorized data mining.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 24]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>Normative References
>
>    [1]  Mockapetris, P., "Domain names - implementation and
>         specification", STD 13, RFC 1035, November 1987.
>
>    [2]  Alvestrand, H., "IETF Policy on Character Sets and Languages",
>         BCP 18, RFC 2277, January 1998.
>
>    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>         Levels", BCP 14, RFC 2119, March 1997.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 25]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>Informative References
>
>    [4]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
>         Protocol (v3)", RFC 2251, December 1997.
>
>    [5]  Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
>         Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
>         June 1997.
>
>    [6]  Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
>         954, October 1985.
>
>    [7]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
>         Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
>         Policy Specification Language (RPSL)", RFC 2622, June 1999.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 26]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>URIs
>
>    [8]   <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
>
>    [9]   <http://www.ietf.org/proceedings/01aug/51-40.htm>
>
>    [10]  <http://www.uwho.verisignlabs.com/
>          Final-WhoIsPanel-Aug15-Resume.pdf>
>
>    [11]  <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/
>          min_database.html>
>
>    [12]  <http://www.nanog.org/mtg-0110/lookup.html>
>
>
>Author's Address
>
>    Andrew L. Newton
>    VeriSign, Inc.
>    21355 Ridgetop Circle
>    Sterling, VA  20166
>    USA
>
>    Phone: +1 703 948 3382
>    EMail: [email-masked]; [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 27]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>Appendix A. Glossary
>
>    o  TLD: Initials for "top level domain." Referes to domains in DNS
>       [1]that are hierarchically at the level just beneath the root.
>
>    o  ccTLD: Initials for "country code top level domain." TLD's which
>       use one of the two character country codes defined by ISO.
>
>    o  gTLD: Initials for "generic top level domain." TLD's that do not
>       use one of the two character country codes defined by ISO.
>
>    o  social data: Data containing names and contact information (i.e.
>       postal addresses, phone numbers, e-mail addresses) of humans or
>       legal entities.
>
>    o  operational data: Data necessary to the operation of networks and
>       network related services and items.
>
>    o  RIR: Initials for "regional Internet registry."
>
>    o  IRR: Initials for "Internet routing registry."
>
>    o  forward lookup: a DNS lookup where a domain name is resolved to an
>       IP address.
>
>    o  reverse lookup: a DNS lookup where an IP address is resolved to a
>       domain name.
>
>    o  mining: In the context of this document, this term is specific to
>       data mining.  This is a methodical process to obtain the contents
>       of directory service, usually as much as possible, not relevant to
>       any immediate need.  Data mining is often not a practice welcomed
>       by registry operators.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 28]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>Appendix B. Acknowledgements
>
>B.1 Forums
>
>    The proceedings of the following public forums were used as input to
>    the scope and requirements for this document:
>
>    o  whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego,
>       CA, USA
>
>    o  whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London,
>       England
>
>    o  First UWho Consultation [10]; August 15, 2001; Washington, DC, USA
>
>    o  Second UWho Consultation; November 15, 2001; Marina del Rey, CA,
>       USA
>
>    o  Third UWho Consultation; November 19, 2001; Washington, DC, USA
>
>    o  DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic
>
>    o  Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech
>       Republic
>
>    o  General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA
>
>    o  DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
>
>    o  Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The
>       Netherlands
>
>    o  NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
>
>    o  CENTR General Assembly, February 21-22, 2002; Rambouillet, France
>
>    o  CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis,
>       Minnesota, USA
>
>
>B.2 Working Group
>
>    This document is a work item of the Cross-Registry Internet Service
>    Protocol (CRISP) Working Group in the Applications Area of the IETF.
>    Discussions for this working group are held on the email list
>    [email-masked].  To subscribe to this email list,
>    send email to [email-masked] with a
>    subject line of "subscribe".  Archives of this list may be found out
>
>
>
>Newton                  Expires August 25, 2003                [Page 29]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    http://lists.verisignlabs.com/pipermail/ietf-not43/.
>
>B.3 Contributions
>
>    Comments, suggestions, and feedback of significant substance have
>    been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr,
>    Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric
>    Hall, Patrick Mevzek, Marcos Sanz, and Vittorio Bertola.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 30]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>Intellectual Property Statement
>
>    The IETF takes no position regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; neither does it represent that it
>    has made any effort to identify any such rights.  Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP-11.  Copies of
>    claims of rights made available for publication and any assurances of
>    licenses to be made available, or the result of an attempt made to
>    obtain a general license or permission for the use of such
>    proprietary rights by implementors or users of this specification can
>    be obtained from the IETF Secretariat.
>
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard.  Please address the information to the IETF Executive
>    Director.
>
>
>Full Copyright Statement
>
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
>
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works.  However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
>
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assignees.
>
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>
>
>
>Newton                  Expires August 25, 2003                [Page 31]
>
>Internet-Draft             crisp-requirements              February 2003
>
>
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>Acknowledgement
>
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Newton                  Expires August 25, 2003                [Page 32]
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

End of GA-DIGEST V1 #1614
*************************