Subject: [Ietf-not43] use case: unwanted email

From: [email-masked] (Liu, Hong)
Date: Fri, 12 Apr 2002 14:52:20 -0500

Andrew,

Please see my comments in line.

Cheers,

--Hong

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]]
Sent: Friday, April 12, 2002 2:45 PM
To: Liu, Hong
Cc: [email-masked]
Subject: RE: [Ietf-not43] use case: unwanted email

On Fri, 2002-04-12 at 13:44, Liu, Hong wrote:
> 
> (1) The real issue in this use case is about finding out the contact
> information of a DNS delegation. This is a general problem regarding stale
> contact information in a registry. I am not sure the federated name scheme
> will solve the problem any better than a thick registry approach. It
really
> boils down to having all registrants cooperate, be it through their own
> servers or through registry policy.

No, you have mixed two of the problem statements with one of the
solutions.  The first problem is that a user does not know where to
start looking.  The second problem is about the delegations.

<HL> 
So let me back off a bit and ask the question: is the respective registry
the natural place to start with? Sure, as you pointed out, the whois
informaiton you get from the query may not be up-to-date or even exist. But
that is a separate probelm. 
<\HL>

> (2) The argument against the thick registry approach is questionable. The
> single point of failure can be resolved by a registry that deploys
redundant
> whois servers.

And who is going to run this uber whois server?  It would make more
sense to take advantage of an existing infrastructure than to build a
new one.  The problem isn't just how I follow the information from
registry to registrar, but also how do I find the proper registry in the
first place.

<HL> 
To your first question, I think any modern web server farm technology will
do to provide the level of redundancy required. If you are talking about
domain names only (forget about RIR for the moment), then (taking your use
case) one can deduce the TLD from the email address, right? Then one can
find out the registry for that TLD. The search space is bounded and is
small, though the whole process may not be fully automated. 

I may be missing something since you emphasize twice about not knowing how
to locate the registry. Could you give me an example?
<\HL>

> (3) It seems that the need to collect information from various sources
other
> than the registry itself is a legacy problem primarily related to thin
> registries. We are well aware of this problem in the .us locality space
and
> we are in the process of consolidating the information using a thick
> registry approach. I am not so sure how frequent this happens to domain
> names under .us, as opposed to those under other more popular thin
> registries. I would suggest that the reference to .us in the use case be
> replaced by a more generic term such as "thin registry".

First off, I'm sorry that .us slipped in there.  I orginially was going
to use some-country.big-state.us as an example for a problem statement
concerning a non-functioning whois server, but I decided to take it
out.  I guess I missed the references to it.

Second, I just checked with my local Internet historian and he assures
me that thick registries walked the earth first.  This possibly places
them in the category of "legacy".

Third, you are right that the reference to .us should come out (see
above).  However, I don't believe the problem is specific to thin or
thick registries.  I just tried the "smart" whois client that comes with
Mandrake 8.2 on fairfax.va.us.  It's answer "This TLD has no whois
server."

<HL> 
The example you cited is exactly the problem we inherited from the previous
(thin) registry. In its true sense, it is a legacy issue, -:)

What I was trying to say is that this is less a problem with the thick
approach than the thin approach.
<\HL>

> (4) It is possible to associate multiple contacts with a domain in EPP.
> There is no limit in the protocol regarding how many contact objects can
be
> associated with a domain object. So if a registrant so chooses to have a
> different contact for handling email abuse, it can create an additional
> admin contact for that purpose. Of course, EPP does not define a contact
> type as "email abuse", but it does relieve the "single contact problem"
> mentioned in your email.

And if registry X decides they don't care to publish such information or
even keep it around...  Besides, what is wrong with allowing registrants
the ability to have their own server in this system?  I know that if I
could do it for my domains, I would be much more likely to keep that
info up to date.  And I'd also have the ability to restrict its use as I
see fit.

<HL>
Sure, a registry can decide what to do with the information and there is
nothing wrong with a registrant providing more information itself. What I
was saying is that mechanisms already exist for thick registries to overcome
the "single contact" problem in your use case. A "good" thick registry
should keep all the registrant-provisioned informaiton related to a domain
and publish it according to the registry contract. Access control is also a
policy issue that can be enforced by a registry.
<\HL>

<HL>
As a general comment, I am not against developing a standard format for
exchanging whois information among registries. I think this is a good thing.
But the use case just does not seem to justify the need to establish a whole
new infrastructure for a problem that could be largely solved by better
registry practice and more cooperative registrant behaviors. I would think
that many registrants are not technically savy enough to maintain their own
servers. So even the latter won't solve the problem completely.
<\HL>

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Fri, 12 Apr 2002 15:18:14 -0500

"Liu, Hong" wrote:

> I may be missing something since you emphasize twice about not knowing
> how to locate the registry. Could you give me an example?

How do I know which WHOIS server to query for the .jp TLD?

Trying a default of whois.jp and whois.nic.jp doesn't work. Nor would it
work for all cases, since I may need to get information for tn.us which
would not match against whois.nic.us (I need whois.nic.tn.us, which
doesn't actually exist).

Secondary to that, how does a server know where to send me for a CIDR
address delegation where the delegations are not on label boundaries?

Referrals are necessary for both the root domains and all resources
throughout all hierarchies.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/