[registrars] [Ietf-not43] new requirements matrix (fwd)
In discussions regarding whois crisp is always mentioned, attached are the requirements and analysis of two competeing protocols attempting to fulfil the requirements. these deserve a good read by anyone wishing to discuss whois protocol requirements as there has been alot of thoughtful communication on the topic in the ietf and i hate to see valuable time wasted by iterating over the same issues in YAF (yet another forum) -rick ---------- Forwarded message ---------- Date: Thu, 22 May 2003 10:49:10 -0400 From: Andrew Newton <anewton@ecotroph.net> To: ietf-not43@lists.verisignlabs.com Subject: [Ietf-not43] new requirements matrix I've attached the requirements matrix as I think it matches to the latest requirements. Of course, if somebody could double check that all the MUST/SHOULD language in the requirements draft is accounted for in the matrix, that'd be swell. For your viewing pleasure, both an ASCII text and HTML version are provided. -andy
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. | | | |
|------------------------------------------------------------------------|
| The protocol MUST provide different error messages to indicate whether |
| the bag is: |
|------------------------------------------------------------------------|
| Unrecognized (permanent failure) | | | |
|------------------------------------+------+-----+----------------------|
| Contains unacceptable data | | | |
| (permenant failure) | | | |
|------------------------------------+------+-----+----------------------|
| Contains data that means | | | |
| processing is refused a this time | | | |
| (transient failure) | | | |
|------------------------------------+------+-----+----------------------|
| There MUST be no more than one bag | | | |
| per referral. | | | |
|------------------------------------+------+-----+----------------------|
| The protocol MUST NOT make an | | | |
| association or linkage between | | | |
| successive bags in a referral | | | |
| chain. | | | |
|------------------------------------+------+-----+----------------------|
| The client MUST pass the bag as | | | |
| part of any query made to a | | | |
| referrant server as a result of a | | | |
| referral. | | | |
|------------------------------------------------------------------------|
| 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. | | | |
+------------------------------------------------------------------------+
Title:
CRISP Technical Proposal Evaluation Matrix
_______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.verisignlabs.com https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||