[ietf-provreg] Is it "social" or is it "model" or is it "mechanism"?

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Oki all,

Back when Ross wrote "Domain Name and Related Definitions", and the latest
copy I have squirreled away in my cache of nuts is -dn-defn-01, May '01 [1],
the defintion offered for "social" and "technical" data was couched in the
language defining the "thick" and "thin" registry models, viz:

   Registry, Thick: A registry in which all of the information
   associated with registered entities, including both technical
   information (information needed to produce zone files) and social
   information (information needed to implement operational, business,
   or legal practices), is stored within the registry repository.

and

   Registry, Thin: A registry in which some element of the social
   information associated with registered entities is distributed
   between a shared registry and the registrars served by the registry.


So in -dn-defn- the model constructed the distinction.

Alternatives models include alternative domain registries, not just
the ICANN gTLD set, and registries that aren't domain registries that
may have a shared-registry model that is object-indifferent.

An alternative to the SRS model constructing what we mean by data of
type 1 and type 2 is to look to the publication mechanism(s). We use
1034/35, and don't mention 954.

An alternative to publication mechanism(s) as a means of constructing
data types (e.g., "social" or "technical"), is meta-data associated
with the data, an approach that is common to both the <dcp> element
form I've proposed, and the <dnp> attribute form the IESG proposes.

A surprisingly large amount of stuff can be published by 1034/35.
We could tighten up "information needed to produce zone files".

A surprisingly large amount of stuff can be published by 954.
We could tighten up "information needed to implement operational,
business, or legal practices".

More care in specification of what is published by 1034/35, and what
is published by 954, doesn't cover publication by other means. It
doesn't cover bulk-transfer. The <recipient> element in the <dcp>
does. Additionally, it doesn't cover correctness, which is equivalent
to defining which instance of a datum is authoritative, and how cache
instances of a datum are made consistent with the authoritative copy.
The <access> element in the <dcp> does. Additionally, it doesn't cover
how long any party (reseller, registrar, registry, others not described,
e.g., ICANN escrow agents) retains any datum, nor what purposes it uses
the datum for during each's period of retention. The <retention> and the
<purpose> elements in the <dcp>, respectively, does.

The IESG's <dnp> attribute provides a binary mechanism for typing. This
has the same limitation as the "more care in specification" approach, and
if scoped, as Scott suggested yesterday, simply reduces those limitations
to a smaller collection of datums -- subsets of the current EPP schemas.

Eric

[1] draft-ietf-provreg-dn-defn-01.txt, expired