<<<
Chronological Index
>>> <<<
Thread Index
>>>
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: <ietf-not43-admin@lists.verisignlabs.com>
>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 (postfix@foxtrot.nic.fr [192.134.4.28])
> by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h1OMbbZL1056794
> for <bortzmeyer@nic.fr>; 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 <bortzmeyer@nic.fr>; 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 <bortzmeyer@nic.fr>; 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: ietf-not43@lists.verisignlabs.com
>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: <3E5A9CF0.2010403@ecotroph.net>
>From: Andrew Newton <anewton@ecotroph.net>
>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: ietf-not43@lists.verisignlabs.com
>Subject: [Ietf-not43] draft-ietf-crisp-requirements-04.txt
>Sender: ietf-not43-admin@lists.verisignlabs.com
>Errors-To: ietf-not43-admin@lists.verisignlabs.com
>X-BeenThere: ietf-not43@lists.verisignlabs.com
>X-Mailman-Version: 2.0.12
>Precedence: bulk
>List-Help: <mailto:ietf-not43-request@lists.verisignlabs.com?subject=help>
>List-Post: <mailto:ietf-not43@lists.verisignlabs.com>
>List-Subscribe: <http://lists.verisignlabs.com/mailman/listinfo/ietf-not43>,
> <mailto:ietf-not43-request@lists.verisignlabs.com?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:ietf-not43-request@lists.verisignlabs.com?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: anewton@verisignlabs.com; anewton@ecotroph.net
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>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
> ietf-not43@lists.verisignlabs.com. To subscribe to this email list,
> send email to ietf-not43-request@lists.verisignlabs.com 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 ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|