[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se, ietf-whois@imc.org
From: George Belotsky <george@register.com>
Date: Fri, 26 Jan 2001 12:07:38 -0500
Content-Disposition: inline
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.2.5i
Subject: Re: Merging RRP and Whois

At this point in the discussion, it helps to summarize some key points.

Those who objected to using the same protocol for the Whois and RRP
have basically made three types of arguments, as listed below.  The
counter-arguments are given along with each type of argument.

1. There is not enough time to consider the Whois extensions.
---
This is not an argument.  The same point can be raised in any context,
on any issue.  Having a deadline does not justify cutting corners.  If
you cut corners to meet a deadline, you have not done your job.  Once
again, the Challenger disaster is the classic example of this.
Launching something 'on time' is no achievement if everyone then has
to deal with the horrible consequences for years afterwards.

2. The Whois is not on my agenda.  I don't want to think about it.
--- 
Protocol design is one of the most difficult tasks in our field of
endeavor -- it requires a lot of thought.  The more inclusive a
protocol is, the more value it has.  In general, a limited protocol is
not worth implementing unless it is very simple.  It is clear that he
RRP has to be a complex protocol.  Thus, every effort should be made
to leverage it as much as possible in sufficiently analogous situations.

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?  Maybe a different keyboard for each
character?  It is possible to find differences in any two things.  The
point is, are they *sufficiently* different to warrant separating
them.  Uniform treatment makes for a consistent view, and greatly
reduces information overload.


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

The Whois functionality will have to be extended. Entities other than
domain names will soon have to be registered, and made accessible in a
Whois-like facility.  The RRP will take considerable effort to
implement.

It is not necessary to decide every single detail now.  The exact form that
the Whois extensions will take, whether the new service will continue
running on port 43, etc. can be taken up by the Whois group in due
course.  

To squander the effort required to adopt the RRP -- by ignoring the
coming needs to extend the Whois and to register other entities --
would be an unforgivable mistake.

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.

Let us not lose the rare opportunity to create a lasting, growing
protocol for working with registered objects on the Internet.  The
problems we disregard today will not disappear tomorrow.  If we are
thus forced to confront them in the near future, the deadlines will
press harder, the work will be considerably larger in scope, and the
mistakes of the past will make a heavy burden.  The most likely result
-- obsolescence of the RRP -- would be a benefit to no-one.

George.


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

Home | Date list | Subject list