Re: Merging RRP and Whois

[George Belotsky <george@register.com>]

I have envisioned the following rough sequence of events/solution as
minimizing the required effort (by the ProvReg group and others) while
maximizing the achieved benefits.  I want to make this explicit, in
case some of the discussion here resulted because of confusion.

  1. The ProvReg group designs a protocol.  This protocol allows/assumes:
      * A centralized object repository (registry) is assumed.
      * The protocol allows registries with different properties to
        be implemented.  The different registries do not have to talk
        to each other.
      * The protocol supports authentication, and grants levels of
        privilege based on the submitted credentials.  Possibilities 
        for access by registrars, registrants, unrelated third parties, etc.
        are all allowed (by the mechanism) and configurable.  The policy for 
        who is finally allowed access would be set elsewhere, and would likely
        vary from registry to registry.
      * Thought is given to future extensions -- but just enough not to cripple 
        the protocol.  This group does not spend much time on this issue, nor
        does it work on the extensions themselves.

  2. The work of the ProvReg group becomes a standard.

  3. The Whois group extends this protocol to handle Whois queries.  The old
     Whois protocol remains, but future development proceeds with the new protocol.
     This work can start even before Step 2, above.

  4. The Whois extensions become standard.

  5. The protocol is extended to objects other than domain names.  This work could 
     possibly start before Step 4, above.


The key concept here (others have proposed similar things as well) is
that the ProvReg protocol becomes the standard method that the world
uses to communicate with a registry.  Thus, we get fewer things that
need to be designed, fewer things that need to be implemented, and --
most importantly -- fewer (diverging) things that need to be
maintained.

George.


On Fri, Jan 26, 2001 at 06:52:43PM +0100, Shane Kerr wrote:
> 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
> 
> 
> 
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
george@register.com
212-798-9127 (phone)
212-798-9876 (fax)