Subject: [Ietf-not43] new requirements matrix

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu May 22 10:35:44 2003

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
-------------- next part --------------
                   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.                         |      |     |                      |
   +------------------------------------------------------------------------+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20030522/24fb9ae6/crisp-matrix-0001.html

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu May 22 10:51:35 2003

Andrew Newton wrote:
> Of course, if somebody could double check that all 

And just five minutes after I sent it out, I have found a substantial 
mistake in one of the matrix items.

So if we could get some independent review of the matrix vs. the 
requirements, that would be great!  It shouldn't take more than 20 
minutes for a person to do.

-andy