Re: Merging RRP and Whois

[Shane Kerr <shane@ripe.net>]

On Fri, 26 Jan 2001, George Belotsky wrote:

> 1. There is not enough time to consider the Whois extensions.
> ---
> This is not an argument.

Agreed here.  If people don't have enough time, then implement now and
standardize later.  IETF is about protocol standards (well, at least
that's what I thought).

> 2. The Whois is not on my agenda.  I don't want to think about it.
> --- 

Well, to be fair, RRP is not on my agenda.  :)  

I think extending RRP to include a read-only mode may have value for
those who use it, but to me that's not the same as merging.  Change the
topic to "Include Whois functionality in RRP" and take the thread off of
the ietf-whois mailing list, I suppose....

> 3. The RRP and Whois are different from each other.
> ---
> The letters 'a' and 'b' are different from each other.  Should I make
> separate keyboards for each one?  <snip/>

I hesitate to extend a possibly bogus analogy, but...do I need a
keyboard that can input Kanji, Arabic, and Cyrillic symbols if I only
speak English?

> Before severely limiting the scope of a complex and extensible
> protocol, the consequences of such an action must be fully realized.

Sure.  But there's a reason that people use Internet protocols (SMTP,
POP/IMAP, RFC822, etc.) and not X.400 for e-mail, and a large part of it
is that X.400 was designed to solve all problems everywhere.  It has a
lot of nice things: delivery receipt, read receipt, message expiry (if
not delivered by a certain date), and so on.  But it's also a fat
bloated pig, and costs a fortune to implement.

> Everywhere, the trend is towards generic programming, polymorphic
> interfaces, and broad standards that unite large problem domains
> across many platforms.  There are strong reasons for these trends.
> The complexity of modern systems, and the speed of their development,
> make it impossible to view things in a fragmented, isolated fashion.
> Broad similarities must be exploited over minute differences to create
> flexible and adaptable solutions.

Maybe.  But we have:

  Whois: anonymous read-only access to something (possibly a database)
    RRP: authenticated read/write access to a domain database

Extending RRP to allow anonymous read-only access is probably
straightforward (said with the eternal optimism of an implmentor).  It
is not clear to me that adding authenticattion OR read/write access to
the Whois protocol make sense.  Again, stop discussing "RRP/Whois merge"
and start talking RRPng and that's fine with me.

If you were to think about extending RRP from a client/server database
to a generic distributed registration database, then I'd love to start
talking.  But the domain folks have quite reasonably decided that this
is a Hard Problem and to concentrate on making a workable business model
instead.  

Are the RRP folks really interested in making a protocol that worries
about object consistency in databases run by their competitors?  If so,
that would be cool, but I just can't imagine any responsible CTO buying
into such a scenerio.  DNS does this, because it's very narrowly
focused with incentives for everybody to carefully manage the data,
without any access concerns (it's all public), and so on.

Personally, I don't think the idea of a global Whois handle nomenclature
really buys that much.  You need to take the next step of actually
allowing foreign data into your registry.  If you're going to do that,
then you need to resolve all the sticky issues that implies.  Again, if
that's really what people want to develop, then lets get into it.  But
if it's not, then please let it die.

So does anybody want to work on that problem in the Whois and/or RRP
group?  Non-heirarchical, distributed registration database.  The topic
of distributed databases has been covered a lot in academia, and we can
steal a lot of work there.  Also, some problems (database partitioning
comes to mind) that PhD-types have spent a lot of time worrying about
can possibly be ignored.  But it's a big, scary, nasty problem.

--
Shane Kerr <shane@ripe.net>
Database Software Engineer
RIPE NCC
+31 20 535 4427