Re: Merging RRP and Whois

["James Seng/Personal" <James@Seng.cc>]

I like to disagree with merging RRP and WHOIS. I think it is a mistake
to merge the two because basically they are designed to solve different
set of problems. Yes, they are related in the sense that they deals with
Domain Names but the similarity ends there.

RRP (or ProReg) is primarly designed in a enviroment where there is
multi-tier tree model. The registrant will send their registration at
the bottom to their reseller, which will then send the registration
upwards to the next level reseller etc until it reaches the registry.

In WHOIS, the model is more top down. The queries goes to the registry
first and then traverse down the tree. In fact, the referer queries may
not even be top-down and may goes side-ways etc.

Ideally, ProReg should be generic enough without been tied down to just
purely Domain Names Registration. There should be generic where by any
multi-tier registration system could use. Our current implementation of
RFC2832 has been extended to handle objects beyond Domain Names. What is
important to specify at the ProReg is the transcation layer which allows
audit and roll-back.

On the other hand, WHOIS is bascically lookup system. Transcation in
this case is not important and in fact, I wouldnt want to leave an audit
trail of WHOIS.

WHOIS have also a different set of problems to solve, such as bulk
lookup.

-James Seng

----- Original Message -----
From: "George Belotsky" <george@register.com>
To: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>
Cc: <ietf-provreg@cafax.se>; <ietf-whois@imc.org>
Sent: Wednesday, January 24, 2001 12:32 AM
Subject: Re: Merging RRP and Whois


> Eric:
>
> I realize the deadlines involved, but it is also important to
> understand that the decisions made now will affect many people for
> years to come.
>
> It is not by accident that most of the great achievements in modern
> times involved the discovery of some unifying principle.  The process
> of unification allows more general constructs to emerge, and these
> constructs ultimately prove more practically useful than a fragmented
> view.
>
> Deadline pressure is today's universal disease -- I am not aware of
> any recent undertaking that has been given a sufficient amount of time
> (or money, for that matter) to be properly completed.  Even in such an
> environment, however, calm and steadfast respect for the fundamental
> nature of the task at hand is the only thing that can assure success.
>
> The loss of the Space Shuttle Challenger readily comes to mind as an
> example of what happens when fundamental nature is ignored.  As
> Richard Feynman said, nature cannot be fooled.  A looming deadline is
> not a reason to try something dangerous.
>
> In many cases, however, a little thought can safely accomodate a
> deadline.  The RRP-Whois unification is one such case.  Already, the
> RRP is being designed to be an extensible protocol.  Given that the
> Whois deadline is still far away, all that would be needed from the
> RRP group is to recognize that there will be one protocol, and leave
> enough hooks so that the Whois part can eventually be built.
>
> The small effort required to unify the two protocols now will save a
> great deal of effort in the future.
>
> On Mon, Jan 22, 2001 at 06:11:34PM -0500, Eric Brunner-Williams in
Portland Maine wrote:
> > George,
> >
> > I brought this up during the BoF in San Diego, if only because I'd
spent
> > the last half of the previous week in Munich with the data
commissioners
> > from Berlin and Schleswig-Holstein ... Jaap made much the same point
in
> > the ietf-whois list w.r.t. the Dutch commissioners in his mail of
Jan 19.
> >
> > Whois (as we know it, aka the absurdly underspecified thingee on
port 43)
> > if used correctly, repurposes and adds 3rd-party recipients to
registrant
> > data, without notice or consent of the registrant.
> >
> > As you note, RRP and Whois both provide views into repositories of
data
> > associated with a transaction, however, the interests of registrants
(and
> > their associated jurisdictions) and the interests of registrars (and
their
> > competitive business models, and eventual liquidators, ala
toysmart's) and
> > the interests of the registries (and their competitive business
models, and
> > eventual successors), aren't trivially reduced to some sensible
service model.
> >
> > I wouldn't assume that the views are equivalent, or the scope of
repository
> > examination (temporal and spatial), or the underlying data, or even
the
> > basic original transaction. Maybe there is just one type of
"original
> > transaction", but I suspect legacy, transfer, bulk and so forth will
have
> > some property which distinguishes them from transactions in which
the role
> > of the registrar is minimal. I'm certain that the underlying data
isn't
> > equivalent, given the repurpose and recipient (marketers, law
enforcement,
> > original jurisdiction) aspects. I'm open on the unified vs disjoint
model
> > for repository examination, and examination ordering. Views just
revisits
> > the purpose and recipient issue, modified by the view construction
policy.
> >
> > One of these two activites is critical infrastructure, the other is
not.
> >
> > One of these two has a hard implementation date, as Ed mentioned,
and the
> > other does not, or has a schedule which requires ICANN's
participation,
> > if not other complications.
> >
> > Cheers,
> > Eric
>
> --
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> george@register.com
> 212-798-9127 (phone)
> 212-798-9876 (fax)