Kerry and all,
Kerry Miller wrote:
> Jeff,
> > > > > 2.) The REGISTRY- Owns the database for the management of
> > > > > information pertaining to all TLD's that are contained within that
> > > > > database.
> ...
> > > sale of 2 is not sale
> > > of the info contained in it, because that info belongs either to 1 or 3.
> >
> > This is not completely correct. Re-read the definition of
> > number 2 again, and it becomes obvious as to why I am saying this
> > if you think about it. >;)
>
> I think there are all sorts of precedent for separating 'management
> of info' from the info itself, and therefore for the separation of rights.
> Dont you?
Yes there has indeed. How that data within that database is managed
is restricted to how it is accessed, not whom or what has access to it.
That functional decision is the sole right of the owner of the data itself.
>
>
> > > > > 3.) The REGISTRAR- Owns the information which relates to the
> > > > > registrar's information services in any TLD name space for which
> > > > > that registrar has permissions from a REGISTRY.
> > > >
> ...
> > > The idea is to prevent polarization; it may be that either 1 or 2 can
> > > *perform the role* of 3, but by setting forth the concept of a
> > > 'middleman,' both can see that the line between them is a pretty
> > > nebulous thing.
> >
> > It is true that Definitions of 1 and 2 could potentially perform some
> > of the functions of 3, but it is not likely that 1 would do so or should
> > do so for obvious reasons. However many of those functions of
> > 3 could be automated to that point, and the need for 3 severely reduced.
> > (BTW, stay tuned, we are working on some of this level of automation
> > currently) >;)
> >
> Indeed, once a role is defined, it almost goes without saying that
> it can be automated -- I expect we'll see 1-rights being allocated
> automatically before too long...
Agreed much of this can be done currently, and to some extend is being done
now. For instance Edgar, is an example...
>
>
> ...
> > it is entirely possible for 1 to
> > operate as 3 in many cases and 3's role to be severely limited.
>
> Of course; definition is one thing; implementation is another...
True, implementation is indeed another... However it is a step that is
doable and is being done in other instances currently.
>
>
> > However 2 must be distinct... 2 and 3 functions could be
> > combined, but it is not advisable to do so for obvious reasons. 1
> > can at some point, with easy to use automation from a web interface
> > provided by 2, could to a great degree supplant 3's existence.
>
> 2 is distinct only by virtue of its uniqueness (and for that reason
> alone, it ought to be as automated as humanly possible), but as
> long as 1s have to *petition to be included in the cosmic database,
> there will be 3-intercessors... Conversely, suppose each human
> birth is *automatically registered -- then 3 is irrelevant.
#, never becomes completely irrelevant, a there will always be those
that prefer someone else to handle the registration of a DN.
>
>
> (Personally, Im an ICANNoclast, but if trading in birth-rights gets
> established then the contact info will need to be changed; and
> since hopefully this process will entail guaranteed support
> ('access') until the seller comes into another name/ domain, there
> are 'enforcement' aspects as well -- so we might do well to keep an
> honorary 3 in place, with very arcane registration-rituals, conducted
> in an independent city-state someplace...)
I feel bad for you here Kerry. Being an ICANNoclast, it I take you meaning
correctly is a very dangerous thing to be if you value your privacy...
>
>
> kerry
>
>
Regards,
--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [EMAIL PROTECTED]
Contact Number: 972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
