Hi Scott,
excuse me if I might sound redundant - but I want to make sure all these issues
are understood and solved.
On 2000/09/11, Hollenbeck, Scott wrote:
> Eric,
>
> I responded to your comment about using name servers as attributes of
> domains last week. If every domain has it's own copy of a server name and
> IP address as an attribute, how would you propose managing a server IP
> address or name change? If I understand correctly, the model you're
> suggesting would require one-by-one modification of every domain that uses
> the server in question -- potentially many thousands of domains in a TLD
> like .com. The model I'm suggesting would require a change to one object --
> the server itself. If you see this differently, please explain how such a
> change could be made managed easily.
Not at all. It requires exactly one domain update per server ip change.
Hence my last email to clarify the model.
The (domain, nserver, glueip) model has the condition that
<glueip> is mandatory if <nserver> has <domain> as parent domain
or otherwise glueip is empty.
So if e.g. ns.abc.tld changes from 1.2.3.4 to 1.2.3.9, all you need is to update
the domain abc.tld to (abc.tld, ns.abc.tld, 1.2.3.9).
Please note the different notion of glue IP vs. nameserver IP.
> I don't see anything in the current grrp draft that discriminates between
> thick or thin models using the definitions of "thick registry" and "thin
> registry" as presented in the draft. As I explained last week when you
> raised these same points, I don't see the problems you've described below in
> a registry environment that is shared by multiple registrars.
Just a second - do you think that those problems:
> 1. can't register nameserver ns.xyz.tld because xyz.tld isn't registered -
> can't register xyz.tld because ns.xyz.tld is its nameserver.
>
> 2. registrar Y can't register abc.tld because its nameserver is ns.uvw.tld,
> but ns.uvw.tld is unregistered and uvw.tld is owned by registrar X.
are not problems / do not occur?
Please understand me right - I don't favorize for thin or thick models from
a technological standpoint. The gRRP definitions for thin or thick are in
relation to the existence of person/contact objects.
What I keep repeatedly talking about is the existence of nameserver objects.
A gRRP should cover at least those 4 variations of models, since it rightfully
identifies 3 distinct entities in a registry: domains, contacts, nameservers.
>
>
>
> Scott Hollenbeck
> VeriSign Global Registry Services
New Signature?
Best,
Eric
>
> -----Original Message-----
> From: Eric Schaetzlein [mailto:eric@schlund.de]
> Sent: Monday, September 11, 2000 7:48 AM
> To: Hollenbeck, Scott
> Cc: 'NSI RRP Mailing List'
> Subject: Re: [NSI-RRP] Name Server Transfers
>
>
> Hi Scott,
>
> you are absolutely right - if we are talking about a thin registry and a
> exTLD nameserver
> (exTLD nameserver = nameserver name in a TLD not sponsored by the registry).
>
> Because then, the nameserver object is nothing more than its primary key,
> the nameserver name.
> (given the last change to your gRRP, that a exTLD nameserver MUST NOT
> contain IP addresses)
>
> In all other cases, that is thick registry (nameserver contains zone-c data)
> or a
> inTLD nameserver (nameserver contains IP addresses) you have an object
> ownership issue.
>
> That ownership issue can be solved in many different ways,
> but the parent domain ownership model creates loops, deadlocks and
> inter-registrar dependencies:
>
> 1. can't register nameserver ns.xyz.tld because xyz.tld isn't registered -
> can't register xyz.tld because ns.xyz.tld is its nameserver.
>
> 2. registrar Y can't register abc.tld because its nameserver is ns.uvw.tld,
> but ns.uvw.tld is unregistered and uvw.tld is owned by registrar X.
>
>
> Now if you go out in the real world and try to find a model that matches
> best reality,
> you'll notice that nameservers are objects shared by multiple registrars but
> really
> "owned" by the zone-c. But there is not zone-c in a thin registry.
>
> So the only reason to create nameservers objects as separate entities in a
> registry
> would be glue records. But glue records are a parameter of (domain,
> nameserver).
> You'll never need 90% of all IP addresses in the registry.
>
> Very rough, it would be like:
> domain: xyz.tld
> nserver: ns.xyz.tld 11.22.33.44
> nserver: ns.uvw.tld
> nserver: ns.aaa.de
>
> ns.xyz.tld needs only a glue record (IN A 11.22.33.44)
> when used as a nameserver for xyz.tld
>
> So, final conclusion, I think the model where nameserver names
> are attributes of domains together with an where-required glue record
> solves a lot of problems. It has been in use in most ccTLD registries
> and therefore been proven as a working model.
>
> I understand this means substantial changes to the current gRRP,
> but a generic RRP which does not consider the protocols that more than
> 200 registries are currently using but rather relies on one special
> RRP (the NSI RRP) model can not be called really "generic" (IMHO).
>
> Best regards,
>
> Eric
>
>
> --
> Eric Schaetzlein Schlund + Partner AG Tel: +49 721 91374
> 50
> Leiter Domain Services Erbprinzenstr. 4-12 Fax: +49 721 91374
> 20
> D-76133 Karlsruhe Mail:
> eric@schlund.de
>
>
>
> On 2000/09/07, Hollenbeck, Scott wrote:
> > I'd like to close on a thought first raised by Eric Schaetzlein regarding
> > name server transfers. Last week we discussed allowing registrar
> transfers
> > for name servers used in a TLD for which a registry is not authoritative.
> > Having had some time to think about it, I'm not sure that there's much
> value
> > in doing this. Here's why:
> >
> > The registry that publishes the zone file containing A records for a
> server
> > controls the association between the server name and IP addresses that
> > appears in the zone. If the name or addresses changes, that can be
> handled
> > within the authoritative registry.
> >
> > Another registry that uses this name server for domains in another TLD
> SHALL
> > NOT publish an A record for this server. There's no "ownership" of this
> > server in this registry, but the registry will publish an NS record for
> the
> > domain(s) served by the server. All this registry needs to know is the
> name
> > of the server, which MAY need to be changed if/when a change is made in
> the
> > authoritative registry. This change can be done by whichever registrar
> > initially added the server to the registry. A registrar transfer would do
> > nothing more than change the registrar capable of changing the name or
> > deleting the server, and I'm not sure there's any real value in this since
> > the real control still resides within the authoritative registry.
> >
> > If anyone disagrees, please explain where you see value in such a change
> of
> > administrative control.
> >
> > Scott Hollenbeck
> > Network Solutions, Inc. Registry
> > ---------
> > See http://www.nsiregistry.com/maillist/rrp/
> > for message archives and subscription management information.
>
> ---------
> See http://www.nsiregistry.com/maillist/rrp/
> for message archives and subscription management information.
Mit freundlichen Gruessen
Eric Schaetzlein
-- Eric Schaetzlein Schlund + Partner AG Tel: +49 721 91374 50 Leiter Domain Services Erbprinzenstr. 4-12 Fax: +49 721 91374 20 D-76133 Karlsruhe Mail: eric@schlund.de--------- See http://www.nsiregistry.com/maillist/rrp/ for message archives and subscription management information.
This archive was generated by hypermail 2b29 : Mon Sep 11 2000 - 09:15:36 EDT