Subject: [ietf-provreg] EPP, data, actors, and access

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 19 Mar 2003 08:35:12 -0500

Oki all,

We have two distinct proposals for a specification of access, data, and
actors for EPP. External to EPP, but possibly relevant, is the existence
of WHOIS (954).

One approach scopes some meta-data to sessions, within a connectionist,
client-server model, with the server originating the meta-data. As a
matter of syntax, this approach is extensible as to semantics associated
with a session.

One approach scopes some meta-data to data only, with the client originating
the meta-data. The syntax for this approach is various, but two designs of
note are an element (in the degenerate case, an attribute only) for some or
all elements of data, and an element for each aggregation of data, e.g., the
contact object, with some mapping to some or all elements of data within the
aggregation.

It is possible that if both a session-scoped mechanism, and a data-scoped
mechanism are presented to a pair of EPP peers, neither being semantically
null, that the peers will not correctly and interoperably evaluate the
semantics of both mechanisms.

This is made more likely if the evaluation-spaces of the two mechanisms
are not identical, nor avail trivial forward and reverse mapping between
nominally equivalent mechanism-specific representations.

A design choice pioneered, at least within the PROVREG context, by one
contributor, is to add a binary toggle, or a set of enumerated values,
that allow some new semantic. As that contributor demonstrated, and as
a subsequent implementations have shown, it is possible to add payload
with a distinct syntactic form. See [1] for details.

I mention this to acknowledge that a WHOIS-specific optimization is a
possibility, that such a "hack" need not conform to the syntax of the
current protocol, and that as an implementation matter, it is tractible.
I add that such an optimization presents challenges for users who may
seek to modify the optimization, or to obtain transparently equivalent
transaction semantics, independent of EPP endpoint operator.

One statement associated with client-origination is that it is actually
registrant-origination. This presents two problems, the first theoretic,
as EPP is between registrars and registries. The working group chose to
create an interoperable protocol for data exchange between registrars and
registries. Some other working group may be formed, if an interoperable
protocol for data exchange between registrants and registrars is useful.

The second problem is user-interface specification. Is the value-space of
the new data binary? Is it an enumerated set?  Is it an enumerated set of
enumerated sets? Is it a tree with some branch ordering and evaluation
property? Isn't this a discussion of what boxes, knobs, and sliders exist
on a registrars registrant-facing data collection API? There are instances
of UI specification within the IETF, but that is not in the PROVREG charter.

I've written quite a bit over the past several months, critically, but
as intelligently as I can manage, on what is referred to as "the IESG
privacy proposal". I have no objective indication that any member of
the IESG has read anything I've contributed to the PROVREG list. That's
OK, this isn't some quest for emotional gratification. What puzzles me
is the utter lack of substantive contribution, whether responsive to
my writings, or those of anyone else, that moves beyond a gesture towards
a requirements statement.

Real requirements are intelligently discussed, unless they arise from
kings, presidents, and voting.

Real proposals are in the form of public drafts, eventually.

Eric

[1] draft-liu-epp-ustld-01.txt, expired. Author at [email-masked].
A copy may exist in the PROVREG list mail archive.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Mar 2003 14:54:03 -0800

>actors for EPP. External to EPP, but possibly relevant, is the existence

You are expressing a very detailed understanding of the problem.  One 
of the issues I have with being this detailed is that it makes the 
chance of consensus less likely to achieve.

I can see the point that perhaps I want my telephone number to appear 
in WHOIS but not in DNS (to pick a perverse situation).

Let's do this as a first order approximation - is it possible to 
specify whether a data item (call it what you will) is not allowed to 
be repeated by the registry to any one other than the registrar that 
submitted it?  Is this something that is common enough to be 
understood by all?  Is this potentially sufficient to satisfy all 
people's needs here?

(Presuming the above meets with consensus, and then while sitting at 
proposed we discover that the mechanism is useless, dropping it or 
replacing it is always an option.  At that time, we will be able to 
point to emperical evidence of the goodness/badness of it.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 19 Mar 2003 18:45:22 -0500

Ed,

A quick reply, between kidz on my end, and distractions on yours.

> understood by all?  Is this potentially sufficient to satisfy all 

The registry can assert that this is its policy via the <dcp>.

Where the value is in having the registrar attempt to bind such a policy
to a data item (I'm partial to mumbles and globs), rather than having a
policy bound to the mumble or glob by the registry is possibly an article
of religious faith.

I've written why the converse is true, possibly in moments of religious
euphoria.

Eric