Subject: [Ietf-not43] IRIS Requirements Compliance Analysis Summary

From: shollenbeck at verisign.com (Hollenbeck, Scott)
Date: Thu Jun 19 11:57:58 2003

These are the results of my analysis of the -02 IRIS specifications to
determine if they meet the -05 requirements.  I'll list each requirement
with a "No" if the requirement does not appear to be met, a "Yes,
<explanation>" if the requirement appears to be met, and "Almost" if the
requirement has been addressed but not completely met.  "Almost" and "No"
results will be addressed in separate messages sent to the WG mailing list.
I've numbered the requirements below to ease identification and reference.

I also found several editorial nits that I've shared with Andy privately.
Since they're not normative I won't flame his spelling prowess publicly...
;-)

A quick summary:

Two requirements (3, 10) appear to be met, but more explanatory text is
needed to explain how the requirement is met.

One requirement (15) is not currently met.

All of the other requirements are clearly met.  Here's the detail, with each
requirement followed by a description:

Section 3.1.2
1. 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.

Yes.  Uses XML Schema and BEEP.

2. The protocol MUST employ the use of network and transport layer standards
as defined by the Internet Engineering Task Force.

Yes.  Uses BEEP and TCP.

3. The protocol MUST define one or more transport mechanisms for mandatory
implementation.

Almost.  BEEP transport is specified as a MUST in section 6.2 of the IRIS
core draft.  BEEP is itself transport-independent, and I can find no mention
of a mandatory BEEP transport protocol.  A TCP port registration request is
included in section 8.3 of the IRIS-BEEP draft, but there's no text to
explain why the registration is present.  Some text needs to be added to the
BEEP draft to cite RFC 3081 as a mandatory transport protocol.  This is
issue #1.

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

Yes.  IRIS includes schema definitions for both domain and address
registries that are specified in XML Schema.

5. there MUST be a means to allow the use of schemas not defined by the
needs of this document.

Yes.  The core specification uses XML Schema abstract elements to allow
unlimited derivations (extensions) of the core elements.  The domain
registry and address registry drafts document derivations of the core
elements.

6. Both types of schemas MUST use the same schema language.

Yes.  All schemas have to be specified in XML Schema.

7. The schemas MUST be able to express data elements with identifying tags
for the purpose of localization of the meaning of the identifying tags.

Yes.  The schemas are capable of including language tagging and character
set identification features.

Section 3.1.4.1
8. The protocol MUST NOT prohibit an operator from granularly assigning
multiple types of access to data according to the policies of the operator.

Yes.  I can find no mention of any features that prohibit an operator from
granting access to data based on operator policies.

9. The protocol MUST provide an authentication mechanism and MUST NOT
prohibit an operator from granting types of access based on authentication.

Yes.  IRIS uses BEEP and the features it includes for authentication
profiles.  I can find no mention of any features that prohibit an operator
from granting access to data based on authentication results.

10. The protocol MUST provide an anonymous access mechanism that may be
turned on or off based on the policy of an operator.

Yes, but it's not obvious.  IRIS depends on BEEP to provide anonymous
access, and this access can be turned on and off by adding or removing BEEP
tuning profiles at the server.  Section 6 of the BEEP draft isn't clear on
how this requirement is met, though, so I would suggest that some additional
text is needed to make the situation more obvious.  This is issue #2.

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

Yes.  Requests and responses are defined using XML.

Section 3.1.6
12. There MUST be a mechanism for an entity contained within a server to be
referenced uniquely by an entry in another server.

Yes.  Section 3.3 of the IRIS core protocol draft describes an entity
identification mechanism to uniquely identify and refer to entities within
and across servers.

Section 3.1.7.1
13. The protocol MUST NOT require the aggregation of data to a central
repository, server, or entity.

Yes.  I can find no mention of any features that require the aggregation of
data to a central repository, server, or entity.

14. The protocol MUST NOT require aggregation of data indexes or hints to a
central repository, server, or entity.

Yes.  I can find no mention of any features that require aggregation of data
indexes or hints to a central repository, server, or entity.

Section 3.1.8.1
15. 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.

No.  There does not appear to be a mechanism provided for a client to
determine if a query will be denied before the query is actually submitted.
This is issue #3.

Section 3.1.9.1
16. The protocol MUST NOT require any Internet registry to participate in
any authentication system.

Yes.  I can find no mention of any features that require an Internet
registry to participate in any authentication system.

17. The protocol MUST NOT prohibit the participation by an Internet registry
in federated, distributed authentication systems.

Yes.  I can find no mention of any features that prohibit the participation
by an Internet registry in federated, distributed authentication systems.

Section 3.1.10
18. The protocol MUST be capable of returning the following types of
non-result or error responses to all lookups and searches:
18a. permission denied - a response indicating that the search or lookup has
failed due to insufficient authorization.

Yes.  This response is described in section 3.2 of the core draft.

18b. not found - the desired results do not exist.

Yes.  This response is described in section 3.2 of the core draft.

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

Yes.  This response is described in section 3.2 of the core draft.

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

Yes.  I can find no mention of any features that prohibit a server from
participating in a query distribution system.

Section 3.1.12.1

20. 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.

Yes.  The protocol version identification and negotiation mechanism is
described in section 2 of the core draft.  BEEP again provides these
features.

21. 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.

Yes.  All schemas are uniquely identified by URIs.

Section 3.1.13.1
22. When issuing a referral, the protocol MUST be capable of supplying a
relay bag from the server to the client,

Yes.  Relay bags are described in section 3.4 of the core draft.

23. and the protocol MUST be capable of allowing the client to submit this
relay bag with a query to the referred server.

Yes.  Relay bags are described in section 3.4 and their use in queries is
described in section 5 of the core draft.

24. The use of the relay bag MUST be OPTIONAL.

Yes.  Relay bag elements include a 'minOccurs="0"' element in section 5 of
the core draft.

25. The protocol MUST NOT make any assumptions regarding the contents of the
relay bag,

Yes.  Section 3.4 of the core draft describes this requirement.

26. but the relay bag MUST be described using the schema language of the
protocol.

Yes.  Relay bag syntax is described in section 5 of the core draft.

27. The protocol MUST provide different error messages to indicate whether
the bag is:
27a. Unrecognized (permanent failure)

Yes.  This response is described in section 3.2 of the core draft.

27b. Contains unacceptable data (permanent failure)

Yes.  This response is described in section 3.2 of the core draft.

27c. Contains data that means processing is refused at this time (transient
failure)

Yes.  This response is described in section 3.2 of the core draft.

28. There MUST be no more than one bag per referral.

Yes.  Relay bag referral elements include a 'maxOccurs="1"' element in
section 5 of the core draft.

29. The protocol MUST NOT make an association or linkage between successive
bags in a referral chain.

Yes.  I can find no mention of any mechanisms that make an association or
linkage between successive bags.

30. The client MUST pass the bag as part of any query made to a referrant
server as a result of a referral.

Yes.  Section 3.4 of the core draft describes this requirement.

Section 3.2.1.1
31. The protocol MUST contain the following lookup functions:
31a. Contact lookup given a unique reference to a contact of a resource.

Yes.  Contact lookup is described in section 3.4 of the domain registry
draft.

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

Yes.  Nameserver lookup is described in section 3.4 of the domain registry
draft.

31c. Domain lookup given a fully-qualified domain name.

Yes.  Domain lookup is described in section 3.4 of the domain registry
draft.

Section 3.2.2.1
32. The protocol MUST contain the following search functions:
Domain name search given an exact match or reasonable subset of a name.

Yes.  Domain search is described in section 3.1.3 of the domain registry
draft.

32a. This search SHOULD allow for parameters and qualifiers designed to
allow better matching of internationalized domain names

Yes.  IDN parameters are described in section 3.1.4 of the domain registry
draft.

32b. and SHOULD allow for both exact and partial matching within the limits
of internationalized domain names.

Yes.  IDN matching is described in section 3.1.4 of the domain registry
draft.

32c. This search SHOULD NOT require special transformations of
internationalized domain names to accommodate this search.

Yes.  IDN search is described in section 3.1.4 of the domain registry draft.

32d. This search MUST provide a means to narrow the search by names
delegated under a particular TLD.

Yes.  A <baseDomain> constraint is described in section 3.1.3 of the domain
registry draft.

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

Yes.  Domain search by registrant is described in section 3.1.2 of the
domain registry draft, and search for contacts (if this requirement means
"searching for registrants") is described in section 3.1.5 of the domain
registry draft.

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

Yes.  Domain search by nameserver is described in section 3.1.6 of the
domain registry draft.

Section 3.2.3.1 
35. 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.

Yes.  IRIS supports all of the attributes and allowable values for contacts,
nameservers, and domains as represented in the two provisioning protocols
that I'm familiar with (RRP and EPP).

36. The schema MUST be capable of expressing the following information for
domains:
36a. activation status

Yes, described in section 3.2.2 of the domain registry draft.

36b. registrant

Yes, described in section 3.2.2 of the domain registry draft.

36c. nameservers

Yes, described in section 3.2.2 of the domain registry draft, but I don't
know if the nameservers are delegated nameservers or subordinate
nameservers.

36d. technical, billing or other contacts

Yes, described in section 3.2.2 of the domain registry draft.

36e. registry delegating the domain

Yes, described in section 3.2.2 of the domain registry draft.

36f. registrar for the domain

Yes, described in section 3.2.2 of the domain registry draft.

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

Yes, described in sections 3.2.2 (<iris:seeAlso>) and 3.3.6.2
(<iris:simpleEntity>) of the domain registry draft.

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

Yes, serialization is described in section 4 of the core draft.

Section 3.2.5.1
39. 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.

Yes, described in section 3.3.6.1 of the core draft.

40. When returning result sets, the protocol MUST be able to make the
following distinctions:
40a. an empty result set.

Yes.  Section 5. of the core draft allows for return of an empty result set.

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

Yes.  An <insufficientResources> error code is described in section 3.2 of
the core draft.  A <searchTooWide> code derivative is also described in
section 3.3.1.

40c. a result set truncated to comply with Section 3.1.1

Yes.  A <limitExceeded> error code is described in section 3.2 of the core
draft.  A <searchTooWide> code derivative is also described in section
3.3.1.

Section 3.2.6.1
41. 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.

Yes.  The delegation authority model is described in sections 3.2.2 and 6 of
the domain registry draft, and section 6 of the address registry draft.

Section 3.2.7.1
42. The protocol MUST NOT prohibit the distribution of data to exclude any
of the registry/registrar models stated in Section 2.1.1.

Yes.  I can find nothing that prohibits the distribution of data.

43. The protocol MUST be capable of expressing referrals and entity
references between the various models described in Section 2.1.1.

Yes.  Entity references and referrals are described in sections 3.3 and 3.4
of the core draft.

Section 3.2.8.1
44. 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:
44a. complete omission of the value without explanation

Yes.  An empty result can be returned as described in section 5 of the core
draft.  In addition, section 3.2.1 of the domain registry draft describes
omission types, including the option for complete omission.

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

Yes.  Described in section 3.2.1 of the domain registry draft.

44c. an indication that the value cannot be given due to privacy constraints
regardless of authorization status

Yes.  Described in section 3.2.1 of the domain registry draft.

45. The protocol MAY define other values for this purpose, but MUST define
values defined above at a minimum.

Yes.  All are described in section 3.2.1 of the domain registry draft.

Section 3.2.9

46. The schema defining domain related resources MUST conform to RFC 2277
[2] regarding textual data.

Yes.  Character set and language identifiers are provided.

47. In particular, the schema MUST be able to indicate the charset and
language in use with unstructured textual data.

Yes.  Character set and language identifiers are provided.

48. The protocol MUST be able to support multiple representations of contact
data, with these  representations complying with the requirements in Section
3.2.3.

Yes.  The ability to support multiple representations of contact data is
described in sections 3.3.2 and 7 of the core draft and section 3.2.5
(<dreg:translatedContact>) of the domain registry draft.

49. The protocol MUST be able to provide contact data in UTF-8

Yes.  XML supports UTF-8.

50. and SHOULD be able to provide contact data in US-ASCII, other character
sets,

Yes.  The ability to support multiple representations of contact data is
described in sections 3.3.2 and 7 of the core draft and section 3.2.5
(<dreg:translatedContact>) of the domain registry draft.

51. and capable of specifying the language of the data.

Yes.  Language tagging is described in several places in the domain registry
draft.

Section 4.1

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

Yes.  BEEP provides this mechanism.

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

Yes.  BEEP provides this mechanism.

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

Yes.  Entity reference and relay bag mechanisms are described in sections
3.3 and 3.4 of the core draft.

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

Yes.  Entity reference and relay bag mechanisms are described in sections
3.3 and 3.4 of the core draft.

Section 4.4
56. To provide for machine consumption as well as human consumption, the
protocol MUST employ structured queries and responses.

Yes.  Query and response formats are specified in XML Schema.

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

Yes.  Uses XML Schema.

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

Yes.  Defines XML schema representations for data exchanged in queries and
responses.

-Scott-