From Internet-Drafts@ietf.org Mon Mar 3 11:46:00 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 03 Mar 2003 06:46:00 -0500 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-requirements-04.txt Message-ID: <200303031146.GAA17937@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Cross Registry Internet Service Protocol (CRISP) Requirements Author(s) : A. Newton Filename : draft-ietf-crisp-requirements-04.txt Pages : 32 Date : 2003-2-28 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-requirements-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-requirements-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-requirements-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-28125053.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-crisp-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-crisp-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28125053.I-D@ietf.org> --OtherAccess-- --NextPart-- From hardie@qualcomm.com Wed Mar 5 19:41:00 2003 From: hardie@qualcomm.com (Ted Hardie) Date: Wed, 5 Mar 2003 11:41:00 -0800 Subject: [Ietf-not43] Agenda for SF IETF meeting Message-ID: <6456CB96-4F42-11D7-93DF-000393CB0816@qualcomm.com> Howdy folks, As you know, we are coming up to the next IETF, and I would like to send an agenda to be posted on the web site. Here's a straw proposal; please send comments to the list. Agenda for CRISP Output from WG Last Call on requirements draft (The last day of the last call is the first day of the IETF meeting; Andy has agreed to present a summary) Updated method for selecting protocol, based on new structure of the requirements draft. Call for volunteers to take on evaluation tasks. Updating milestones. AOB From hardie@qualcomm.com Tue Mar 11 18:33:03 2003 From: hardie@qualcomm.com (Ted Hardie) Date: Tue, 11 Mar 2003 10:33:03 -0800 Subject: [Ietf-not43] New co-chair Message-ID: Hi folks, I'm happy to announce the April Marine has agreed to serve as co-Chair of the CRISP working group. For those of you who do not know April, she is a former IESG member and a long-time IETF contributor in both the Applications and User Services area (now part of the General area). Given her long experience with administrative directory services and the processes of the IETF, I'm very pleased to have her take this role, and I hope you'll join me in welcoming her. As part of the other shifts related to my taking on new roles in the IETF, Ned Freed will also be taking over as area advisor for the group after the end of the San Francisco meeting. My thanks and welcome to them both, regards, Ted Hardie (now co-)Chair, CRISP From hardie@qualcomm.com Wed Mar 12 00:08:49 2003 From: hardie@qualcomm.com (Ted Hardie) Date: Tue, 11 Mar 2003 16:08:49 -0800 Subject: [Ietf-not43] CRISP Agenda for SF IETF meeting In-Reply-To: <6456CB96-4F42-11D7-93DF-000393CB0816@qualcomm.com> Message-ID: IETF 56 CRISP Chairs: April Marine, Ted Hardi Agenda Bashing Review output from working group last call of requirements draft. Andy Newton Review of method for selecting protocol Chairs Call for volunteers for specific evaluation elements Chairs All other business Time permitting, Leslie Daigle will present "IRIS light"; this is not intended as a working group document, but relates to some of the documents under evaluation. From wessorh@ar.com Wed Mar 12 00:40:21 2003 From: wessorh@ar.com (Rick Wesson) Date: Tue, 11 Mar 2003 16:40:21 -0800 (PST) Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt In-Reply-To: <5.1.0.14.2.20030224144511.00a7c528@mage.qualcomm.com> Message-ID: > After reviewing the document, I'd appreciate it if working group members sent > a note to the list indicating that they have completed their review and their > statement on the document. I'm still reviewing it... i hope to have my comments to the list latter this week. -rick From Ross Wm. Rader" Message-ID: <00d701c2e846$802f1840$7902a8c0@VALUEDD9017A01> > I'm still reviewing it... i hope to have my comments to the list latter > this week. I'm running behind as well. Comments to follow... Regards, -rwr "There's a fine line between fishing and just standing on the shore like an idiot." - Steven Wright Got Blog? http://www.byte.org From ggm@apnic.net Mon Mar 17 22:12:51 2003 From: ggm@apnic.net (George Michaelson) Date: Tue, 18 Mar 2003 08:12:51 +1000 Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt In-Reply-To: Your message of "Tue, 25 Feb 2003 04:45:56 -0500." Message-ID: <17397.1047939171@wl-131-245.wireless.ietf56.ietf.org> For extensibility reasons I feel it would be better if the document was re-written into a base/general part, and a domain specific part. It would permit future liaison and involvement from other interests. I realize this is a shame this late in the document cycle, but I think a couple of weeks work could deliver a better longterm structure. cheers -George From plzak@arin.net Mon Mar 17 22:24:40 2003 From: plzak@arin.net (Ray Plzak) Date: Mon, 17 Mar 2003 17:24:40 -0500 Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt In-Reply-To: <17397.1047939171@wl-131-245.wireless.ietf56.ietf.org> Message-ID: <001801c2ecd4$00f89c30$298888c0@arin.net> Sounds reasonable to me. Ray > -----Original Message----- > From: ietf-not43-admin@lists.verisignlabs.com > [mailto:ietf-not43-admin@lists.verisignlabs.com] On Behalf Of > George Michaelson > Sent: Monday, March 17, 2003 5:13 PM > To: Leslie Daigle > Cc: Ted Hardie; Andrew Newton; ietf-not43@lists.verisignlabs.com > Subject: Re: [Ietf-not43] WG Last call: > draft-ietf-crisp-requirements-04.txt > > > For extensibility reasons I feel it would be better if the document > was re-written into a base/general part, and a domain specific part. > > It would permit future liaison and involvement from other interests. > > I realize this is a shame this late in the document cycle, but I think > a couple of weeks work could deliver a better longterm structure. > > cheers > -George > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > From fneves@registro.br Mon Mar 17 22:26:22 2003 From: fneves@registro.br (Frederico A C Neves) Date: Mon, 17 Mar 2003 19:26:22 -0300 Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt In-Reply-To: <17397.1047939171@wl-131-245.wireless.ietf56.ietf.org> References: <17397.1047939171@wl-131-245.wireless.ietf56.ietf.org> Message-ID: <20030317222622.GA44824@registro.br> Looks as a good path to follow, Regards, Frederico On Tue, Mar 18, 2003 at 08:12:51AM +1000, George Michaelson wrote: > For extensibility reasons I feel it would be better if the document > was re-written into a base/general part, and a domain specific part. > > It would permit future liaison and involvement from other interests. > > I realize this is a shame this late in the document cycle, but I think > a couple of weeks work could deliver a better longterm structure. > > cheers > -George From cathym@arin.net Mon Mar 17 22:30:25 2003 From: cathym@arin.net (Cathy Murphy) Date: Mon, 17 Mar 2003 17:30:25 -0500 (EST) Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt In-Reply-To: <17397.1047939171@wl-131-245.wireless.ietf56.ietf.org> Message-ID: On Tue, 18 Mar 2003, George Michaelson wrote: > For extensibility reasons I feel it would be better if the document > was re-written into a base/general part, and a domain specific part. I concur. I think splitting the requirements document into some very generic requirements that apply to other types of registry operations and requirements for domain registries will facilitate extensibility. > It would permit future liaison and involvement from other interests. > > I realize this is a shame this late in the document cycle, but I think > a couple of weeks work could deliver a better longterm structure. Agreed. Expect specific comments on the document to follow shortly. -Cathy > > cheers > -George > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > From anewton@ecotroph.net Wed Mar 26 18:44:39 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 26 Mar 2003 13:44:39 -0500 Subject: [Ietf-not43] crisp requirements matrix Message-ID: <3E81F517.7030209@ecotroph.net> This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak-3288-1048704565-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here is a first pass at the crisp requirements matrix. The entries are based on the latest draft in the repository. Therefore, they will change with the addition of the new text from the comments period and the expected comments due in about 2 weeks. If you have comments on the format or structure of the matrix, please send them to the list. It is provided in both HTML and ASCII text format. -andy --=_zak-3288-1048704565-0001-2 Content-Type: text/plain; name="crisp-matrix.txt"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="crisp-matrix.txt" CRISP Technical Proposal Evaluation Matrix +------------------------------------------------------------------------+ | Requirement | IRIS | LW | Comment | |------------------------------------------------------------------------| | Sample | |------------------------------------------------------------------------| | The protocl MUST be capable of | NO | YES | IRIS only gives the | | walking and chewing gum at the | | | appearance of | | same time. | | | walking and chewing | | | | | gum simultaneously, | | | | | but it in fact | | | | | requires two | | | | | separate CPU clock | | | | | cycles. On the other | | | | | hand, LW does the | | | | | walking on the | | | | | rising edge of the | | | | | cycle and the gum | | | | | chewing on the | | | | | falling edge of the | | | | | cycle. | |------------------------------------------------------------------------| | Section 3.1.2 | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.3.1 | |------------------------------------------------------------------------| | The protocol MUST contain standard | | | | | schemas for the exchange of data | | | | | needed to implement the | | | | | functionality in this document. | | | | |------------------------------------+------+-----+----------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.4.1 | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.5 | |------------------------------------------------------------------------| | The protocol MUST be capable of | | | | | allowing machine parsable requests | | | | | and responses. | | | | |------------------------------------------------------------------------| | Section 3.1.6 | |------------------------------------------------------------------------| | The protocol MUST be capable of | | | | | allowing machine parsable requests | | | | | and responses. | | | | |------------------------------------------------------------------------| | Section 3.1.7.1 | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.8.1 | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.9.1 | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.10 | |------------------------------------------------------------------------| | The protocol MUST be capable of returning the following types of | | non-result or error responses to all lookups and searches: | |------------------------------------------------------------------------| | permission denied - a response | | | | | indicating that the search or | | | | | lookup has failed due to | | | | | insufficient authorization. | | | | |------------------------------------+------+-----+----------------------| | not found - the desired results do | | | | | not exist. | | | | |------------------------------------+------+-----+----------------------| | insufficient resources - the | | | | | search or lookup requires | | | | | resources that cannot be | | | | | allocated. | | | | |------------------------------------------------------------------------| | Section 3.1.11.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit a | | | | | server from participating in a | | | | | query distribution system. | | | | |------------------------------------+------+-----+----------------------| | Section 3.1.12.1 | | | | |------------------------------------+------+-----+----------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.13.1 | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.2.1.1 | |------------------------------------------------------------------------| | The protocol MUST contain the following lookup functions: | |------------------------------------------------------------------------| | Contact lookup given a unique | | | | | reference to a contact of a | | | | | resource. | | | | |------------------------------------+------+-----+----------------------| | Nameserver lookup given a | | | | | fully-qualified host name or IP | | | | | address of a nameserver. | | | | |------------------------------------+------+-----+----------------------| | Domain lookup given a | | | | | fully-qualified domain name. | | | | |------------------------------------------------------------------------| | Section 3.2.2.1 | |------------------------------------------------------------------------| | The protocol MUST contain the following search functions: | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------+------+-----+----------------------| | Domain registrant search by either | | | | | exact name or partial name match | | | | | with the ability to narrow the | | | | | search to registrants of a | | | | | particular TLD. | | | | |------------------------------------+------+-----+----------------------| | Domains hosted by a nameserver | | | | | given the fully-qualified host | | | | | name or IP address of a | | | | | nameserver. | | | | |------------------------------------------------------------------------| | Section 3.2.3.1 | |------------------------------------------------------------------------| | 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: | |------------------------------------------------------------------------| | activation status | | | | |------------------------------------+------+-----+----------------------| | registrant | | | | |------------------------------------+------+-----+----------------------| | nameservers | | | | |------------------------------------+------+-----+----------------------| | technical, billing or other | | | | | contacts | | | | |------------------------------------+------+-----+----------------------| | registry delegating the domain | | | | |------------------------------------+------+-----+----------------------| | registrar for the domain | | | | |------------------------------------+------+-----+----------------------| | The data set for domains MUST be | | | | | able to express arbitrary textual | | | | | information for extensions on an | | | | | individual operator basis. | | | | |------------------------------------------------------------------------| | Section 3.2.4 | |------------------------------------------------------------------------| | The schemas used by the protocol | | | | | SHOULD be capable of off-line | | | | | serialization. | | | | |------------------------------------------------------------------------| | Section 3.2.5.1 | |------------------------------------------------------------------------| | 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: | |------------------------------------------------------------------------| | an empty result set. | | | | |------------------------------------+------+-----+----------------------| | a result set truncated for the | | | | | purpose of improving performance | | | | | bottlenecks. | | | | |------------------------------------+------+-----+----------------------| | a result set truncated to comply | | | | | with Section 3.1.1 | | | | |------------------------------------------------------------------------| | Section 3.2.6.1 | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.2.7.1 | |------------------------------------------------------------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.2.8.1 | |------------------------------------------------------------------------| | 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: | |------------------------------------------------------------------------| | complete omission of the value | | | | | without explanation | | | | |------------------------------------+------+-----+----------------------| | an indication that the value | | | | | cannot be given due to | | | | | insufficient authorization | | | | |------------------------------------+------+-----+----------------------| | 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. | | | | |------------------------------------------------------------------------| | Section 3.2.9 | |------------------------------------------------------------------------| | 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 | | | | | | | | | | US-ASCII, other character sets, | | | | |------------------------------------+------+-----+----------------------| | and capable of specifying the | | | | | language of the data. | | | | |------------------------------------------------------------------------| | Section 4.1 | |------------------------------------------------------------------------| | Entities accessing the service | | | | | (users) MUST be provided a | | | | | mechanism for passing credentials | | | | | to a server for the purpose of | | | | | authentication. | | | | |------------------------------------------------------------------------| | Section 4.2 | |------------------------------------------------------------------------| | The protocol MUST provide a | | | | | mechanism capable of employing | | | | | many authentication types and | | | | | capable of extension for future | | | | | authentication types. | | | | |------------------------------------------------------------------------| | Section 4.3 | |------------------------------------------------------------------------| | To distribute queries for search | | | | | continuations and to issue entity | | | | | references, the protocol MUST | | | | | provide a referral mechanism. | | | | |------------------------------------------------------------------------| | Section 4.4 | |------------------------------------------------------------------------| | To distribute queries for search | | | | | continuations and to issue entity | | | | | references, the protocol MUST | | | | | define a common referral scheme | | | | | and syntax. | | | | |------------------------------------+------+-----+----------------------| | Section 4.5 | | | | |------------------------------------+------+-----+----------------------| | To provide structured queries and | | | | | responses and allow for minimal | | | | | technological reinvention, the | | | | | protocol MUST employ a | | | | | pre-existing schema language. | | | | |------------------------------------+------+-----+----------------------| | Section 4.6 | | | | |------------------------------------+------+-----+----------------------| | To provide for machine consumption | | | | | as well as human consumption, the | | | | | protocol MUST define schemas for | | | | | use by the structured queries and | | | | | responses. | | | | +------------------------------------------------------------------------+ --=_zak-3288-1048704565-0001-2 Content-Type: text/html; charset=utf-8; name="crisp-matrix.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="crisp-matrix.html"

CRISP Technical Proposal Evaluation Matrix


Requirement

IRIS

LW

Comment

Sample

The protocl MUST be capable of walking and chewing gum at the same time.

NO

YES

IRIS only gives the appearance of walking and chewing gum simultaneously, but it in fact requires two separate CPU clock cycles. On the other hand, LW does the walking on the rising edge of the cycle and the gum chewing on the falling edge of the cycle.

Section 3.1.2

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.




Section 3.1.3.1

The protocol MUST contain standard schemas for the exchange of data needed to implement the functionality in this document.




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.




Section 3.1.4.1

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.




Section 3.1.5

The protocol MUST be capable of allowing machine parsable requests and responses.




Section 3.1.6

The protocol MUST be capable of allowing machine parsable requests and responses.




Section 3.1.7.1

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.




Section 3.1.8.1

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.




Section 3.1.9.1

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.




Section 3.1.10

The protocol MUST be capable of returning the following types of non-result or error responses to all lookups and searches:

permission denied - a response indicating that the search or lookup has failed due to insufficient authorization.




not found - the desired results do not exist.




insufficient resources - the search or lookup requires resources that cannot be allocated.




Section 3.1.11.1

The protocol MUST NOT prohibit a server from participating in a query distribution system.




Section 3.1.12.1




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.




Section 3.1.13.1

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.




Section 3.2.1.1

The protocol MUST contain the following lookup functions:

Contact lookup given a unique reference to a contact of a resource.




Nameserver lookup given a fully-qualified host name or IP address of a nameserver.




Domain lookup given a fully-qualified domain name.




Section 3.2.2.1

The protocol MUST contain the following search functions:

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.




Domain registrant search by either exact name or partial name match with the ability to narrow the search to registrants of a particular TLD.




Domains hosted by a nameserver given the fully-qualified host name or IP address of a nameserver.




Section 3.2.3.1

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:

activation status




registrant




nameservers




technical, billing or other contacts




registry delegating the domain




registrar for the domain




The data set for domains MUST be able to express arbitrary textual information for extensions on an individual operator basis.




Section 3.2.4

The schemas used by the protocol SHOULD be capable of off-line serialization.




Section 3.2.5.1

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:

an empty result set.




a result set truncated for the purpose of improving performance bottlenecks.




a result set truncated to comply with Section 3.1.1




Section 3.2.6.1

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.




Section 3.2.7.1

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.




Section 3.2.8.1

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:

complete omission of the value without explanation




an indication that the value cannot be given due to insufficient authorization




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.




Section 3.2.9

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

US-ASCII, other character sets,




and capable of specifying the language of the data.




Section 4.1

Entities accessing the service (users) MUST be provided a mechanism for passing credentials to a server for the purpose of authentication.




Section 4.2

The protocol MUST provide a mechanism capable of employing many authentication types and capable of extension for future authentication types.




Section 4.3

To distribute queries for search continuations and to issue entity references, the protocol MUST provide a referral mechanism.




Section 4.4

To distribute queries for search continuations and to issue entity references, the protocol MUST define a common referral scheme and syntax.




Section 4.5




To provide structured queries and responses and allow for minimal technological reinvention, the protocol MUST employ a pre-existing schema language.




Section 4.6




To provide for machine consumption as well as human consumption, the protocol MUST define schemas for use by the structured queries and responses.





--=_zak-3288-1048704565-0001-2-- From ehall at ehsco.com Mon Mar 31 15:39:37 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Mar 31 16:39:44 2003 Subject: [Ietf-not43] contact lookups: the elephant in my room Message-ID: <3E88B599.1090307@ehsco.com> I'm trying to figure out exactly what kind of search-by-email needs to be supported in the LDAP-WHOIS spec. draft-ietf-crisp-requirements-04.txt requires the following: | 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. This can mean several different things. As two examples of this, it can mean that the globally distributed database of "domains" must be searchable by some kind of contact identifier, or it can mean that some other [different] globally distributed database of "contacts" must be searchable by some kind of contact identifier. It can also mean both, and it can also mean a whole lot more databases will eventually need to be searchable as well (substitute IPV4/IPV6/ASN databases for the "domain" database and you see that we are talking about a lot of databases). Both of those interpretations have different ramifications. On the one hand, searching a distributed database (domains in this case) by attribute value isn't pretty. It isn't something that's done with any other protocol in the IETF space (the closest we came was IQUERY in DNS, which was deprecated last year). We've kind of bounced off this topic a few times, but frankly, at this point the technology is more appropriate for doctoral thesis papers than practical application. Exactly how is a server supposed to say "I don't have any matches, go try some infinitely and recursively large array of other servers". If this interpretation is scaled back some -- just query a specific server for the attribute values, effectively reinvinting IQUERY with all of its limitations -- that is certainly doable but it is kind of a metaphorical change from other searches that we are already doing. We have to ask for the identifier (presumably a name and/or an email address) along with the scope they want to search within (ask the .com servers only), and not do referrals. This is tantamount to being an ugly hack and one which doesn't actually solve the canonical problem of finding contacts. The other interpretation does solve the problem, but it introduces a management issue, which is that we aren't claiming authority over contact information. If we say "okay there is also some amorphous table of contact data in the system, go search that", then we are all of a sudden outside the domain space, which is all we are "authorized" for. I can do both of these approaches, and although I'd rather just do one (the latter in particular), that's not really the problem I'm asking about. What I'm asking about is, which interpretation exactly do we want to use as a group? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/