Subject: [Ietf-not43] IRIS issue summary

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Sep 4 01:56:37 2003

Since the discussion period is closing, I wanted to summarize the issues
I've noted with IRIS for convenience. Some of these apply to the technical
requirements but most of them are architectural concerns. Most of the
points have recommendations. As any of the issues are dealt with (and Andy
has expressed an interest in dealing with at least some of them), they
should be redacted from the list.

I invite Andy or anybody else to do the same with FIRS.

1. IRIS uses IDNA domain names, which don't support substring searches

Andy seems to be on top of this, but to reiterate the problem, IDNA
encodings don't support sub-string matches. Specifically, something like
f?o (xn--fo-fka) will not match f?obar (xn--fobar-jua). An encoding form
that accurately represents the UCS character sequences is needed.

My suggestion is that the protocol should use a single UTF-8 syntax for
all domain-related queries.

2. IRIS currently advocates separate query paths for UTF-8 IDNs

I don't know what direction Andy has settled on with this, but it's still
an open issue at the moment. As has been pointed out already, the use of
multiple query paths means supporting twice the named queries (read:
debugging), managing twice the entries in the global database (read:
synchronization), and so forth.

My suggestion is that the protocol should use a single UTF-8 syntax for
all domain-related queries.

3. IRIS currently does not support IDNs in email addresses

Andy appears to be on this too.

My suggestion is that the protocol should use a single UTF-8 syntax for
all domain-related queries (and this includes the domain element of an
email address).

4. IRIS doesn't support "lookups" in the technical sense

More accurately, IRIS doesn't have a global namespace that key values can
be compared against. A lookup is generally considered to be a
value-comparison betwein an input and a database or index. In the case of
CRISP, the "database" is distributed, with different partitions managing
subsets of the database. Usually these kinds of systems have a namespace
which acts as an index, but IRIS doesn't provide one. Instead, IRIS uses
pre-packaged queries that identify the specific partition for a query. In
general terms, this means that knowing the resource' name alone is
meaningless: is eh26 for netsol or for arin, or worse, is www.example.com
for com or for example.com? It's impossible to tell without possessing
extra-name information, meaning that the primary data-values are useless
as lookup keys. Without a hierarchiocal namespace of identifiers or an
extra-service index, "lookups" of data values are impossible in the
traditional sense. This has a significant impact on future uses, where
fetches of specific attributes associated with specific resource entries
are too vague to be used successfully.

In order to fix this, entry names should be structured as a hierarchical
namespace, and the URI syntax should recognize and accomodate this
namespace, thereby allowing application clients to issue lookups without
requiring any additional parameters.

5. IRIS doesn't provide a generalized query syntax

Entries can only be queried by way of pre-defined query-types, instead of
generalized syntaxes or generalized query types. Existing data which does
not have a formal query-type cannot be searched (eg, street addresses
cannot be searched for all instances of a common post-office box) and new
data cannot be queried until new named searches are standardized (eg,
operator-provided "expires" attributes cannot be searched).

At the very least, IRIS should provide a generic "equality-for-type"
search mechanism that allows a query to identify the attribute and value
which should be searched. A more robust approach would provide multiple
types for any value, but that's probably too much work.

6. IRIS does not provide an extension-negotiation mechanism

There is no defined mechanism for advertising the presence of schema
extensions (such as new attributes), or for advertising any new queries
which may be associated with those extensions. Lacking such a mechanism,
the only formal way to introduce any new elements is to upgrade the core
specifications, and reboot with a version number bump.

IRIS should provide an extension-negotiation mechanism.

7. IRIS cannot be unilaterally extended by providers

If the only way to get new sub-schema and queries recognized by clients is
to upgrade the core specs, then every extension will need to be debated
for merit, with the competitive benefits for the proponent being weighed
against the cost burdens of the disinterested and the unaffected, and the
business interests of the proponent's competitors.

Very few IETF protocols have been published that are non-extensible, and
of those, all of them have had extension capabilities grafted on
afterwards, sometimes in very ugly ways.

IRIS must provide either a generalized query syntax or extension
negotiation, and preferably both.

8. IRIS is read-only

Although the CRISP charter (as clarified) is specifically limited to
read-only usages, there are other layered services that we already know
about that will require read-write capabilities. The lack of an "update"
mechanism (nevermind an "add" mechanism) is a major limitation on future
usage. Those applications will not benefit from having to support
different services for reading published data versus writing the same
data, meaning that these applications will generally favor some other
technology that provides both. As such, failure to provide read-write
capabilities here (even if we don't use it with delegations) is likely to
mean that yet-another distributed database will have to be invented to
support them. Moreover, the providers in the CRISP system will likely have
to play in that system as well, so going with a read-only system now
pretty much equates with managing two systems later.

I don't have a recommendation here, since "add an update verb" involves
huge amounts of effort that is not justifiable given the current scope.

I would point out that the existence of write support does not mean that
writes have to be allowed. EG, Dynamic DNS might allow the creation of
zones, but that doesn't mean anybody in their right mind thinks it should
be used for zone delegations, although it is provably useful for managing
attributes and values within the zones that have been delegated.

9. IRIS doesn't allow per-attribute fetches

It's not possible for the client to request that responses be constrained
to one or more specific attributes. There are numerous issues here:
bandwidth and latency concerns for heavily-extended datasets are
relatively obvious (assuming they get facilitated at some point), but
there are also data-pollution issues. EG, a value for a sibling attribute
in a ~registry data-store could be mis-applied to a subsequent query for
that attribute in the operator's partition. There is potential for
something like a routing service to go wobbly when the registry for the
address space says "here's the outdated routing data for that netblock"
for all queries.

IRIS should provide the ability for clients to limit responses to a
specific set of attributes.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu Sep 4 03:41:45 2003

Eric A. Hall wrote:
> 
> As has been pointed out already, the use of

This statement makes a very large assumption about the implementation of 
the back-end.  Many back-ends can accomodate this without any of the 
problems you just mentioned.  Perhaps it is only a problem when dealing 
with off-the-shelf generalized data-stores that insist on enforcing a 
tree structure for everything, but any properly focused back-end will 
not have these troubles.

> 4. IRIS doesn't support "lookups" in the technical sense

This is inaccurate.

> requiring any additional parameters.

Just because IRIS does not take contact handles and turn them into a 
universal key does not mean there is no support of lookups.

> Lacking such a mechanism,

This is also inaccurate.

-andy