RE: [NSI-RRP] FW: I-D ACTION:draft-hollenbeck-grrp-reqs-03.txt

From: Hollenbeck, Scott (shollenb@netsol.com)
Date: Wed Aug 30 2000 - 08:09:35 EDT


Eric,

I'll respond to your questions below.

Scott Hollenbeck
Network Solutions, Inc. Registry

-----Original Message-----
From: Eric Schaetzlein [mailto:eric@schlund.de]
Sent: Tuesday, August 29, 2000 2:18 PM
To: Hollenbeck, Scott
Cc: rrp@nsiregistry.com
Subject: Re: [NSI-RRP] FW: I-D ACTION:draft-hollenbeck-grrp-reqs-03.txt

On 2000/08/29, Hollenbeck, Scott wrote:
> Eric,
>
> If we assume that "company.tld" and "subsidiary.tld" are available and
that
> the Registry is authoritative for ".tld"...
>
> 1. Company registers "company.tld" through Registrar X: This works.
>
> 2. Subsidiary registers "subsidiary.tld" through Registrar Y: This works.
>
> 3. Registrar Y can register "product.tld" for either company or subsidiary
> if it's available. This works.
>
> 4. Registrar Y can register "ns1.subsidiary.tld". This works.
>
> 5. Why should registrar Y be able to register a name server
> (ns1.subsidiary.company.tld) in a domain (company.tld) sponsored by
> Registrar X?

Well, simply because they are to register the domain "product.tld"
and cannot do so until the nameserver is registered.
I mean, from a reality standpoint, why should Registrar Y depend on
Registrar X
to depend the still-available domain "product.tld"?

[SAH] Because Registrar Y is trying to create something in a TLD whose
registration is administered by Registrar X.

> Registrar X can register "ns1.subsidiary.company.tld" because
> it sponsors the registration of "company.tld". Subsidiary can (and I
> believe should) register the name server through Registrar X.

But this is a heck more complicated to explain to a customer if you are
Registrar Y.

[SAH] I don't think so. I think it gets a lot more complicated if name
server management gets "decentralized", as I'll explain in response to your
next suggestion.

> This seems a lot less uglier to me than allowing multiple registrars to
> manage the name servers in an SLD like "company.tld".

Why don't we try to sum up all possibilities that could happen in that case?
Basically, a nameserver is owned by the zone-c or the nameserver operator,
and not
the Registrar. And nameservers are shared between lots of different domains,
in many
different Registries and between different Registrars.
That's where the gRRP model - IMHO - does not catch the concept of a
nameserver
in the real world.

[SAH] OK, here are some problem possibilities:

1. Let's assume that RegistrarX is responsible for example.tld. RegistrarY
is responsible for server ns1.example.tld, and RegistrarZ is responsible for
server ns2.example.tld. All three registrars exist in different countries,
subject to different local and national laws. A court in RegistrarX's
country tells RegistrarX to delete example.tld for some reason. I contend
that removing example.tld should also remove all name servers under
example.tld, in this case ns1.example.tld and ns2.example.tld, because not
doing so leaves "orphaned" name servers in the Registry and publishing such
servers in a zone file will cause resolution problems. RegistrarX can't
delete the name servers because they are managed by Registrars Y and Z.
RegistrarX has to ask the two other registrars to delete the name servers
before it can delete example.tld. RegistrarY refuses, because it has
customers that use ns1.example.tld and the laws in RegistrarX's country
don't apply in RegistrarY's country. Now RegistrarX is stuck -- it can't
remove example.tld, and if we create a system that does allow remove of
example.tld without removing the name servers in example.tld we end up
putting bogus data in zone files.

2. Now suppose that instead of having a name server object we allow name
servers and their addresses to exist only as attributes of a domain name.
We can't require uniqueness for the server name, so we now have the
possibility of every registrar creating their own copy of ns1.example.tld
with an unlimited number of potentially different IP addresses, each of
which ends up in the zone file as an A record. If the address of the server
changes, the change must be coordinated among every registrar who is using
the server, who has to modify every domain that is using the server
(potentially many thousands), and there's no guarantee that any or all of
the registrars will respond. I'd rather deal with one registrar in this
case than with several, some of whom I may not even be aware of.

I still think that name server objects that are tied to the parent domain
provides the most reasonable compromise. I'm still thinking about a way to
optimize the "use of a name server from a non-authoritative TLD" situation
that you described, because I agree that there can be management problems
when there is no parent domain for which the registry is authoritative.
Maybe it does make sense to allow transfer of this type of name server.
---------
See http://www.nsiregistry.com/maillist/rrp/
for message archives and subscription management information.



This archive was generated by hypermail 2b29 : Wed Aug 30 2000 - 08:10:07 EDT