RE: 3.4/Object Ownership, esp. Name Server Ownership

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

>-----Original Message-----
>From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
>Sent: Wednesday, April 11, 2001 5:33 AM
>To: Hollenbeck, Scott; ietf-provreg@cafax.se
>Subject: 3.4/Object Ownership, esp. Name Server Ownership
>
>
>
>
>Hallo!
>
>One thing I nearly forgot is the question of object ownership. The section
3.4
>is a bit unspecific to this topic. In the spec the term "sponsoring
registrar"
>appears, which obviously describes the ownership of an object. On the first
>view one could think that the registrar which creates an object
automatically
>owns/sponsors this object. But section "3.4.5 Object Transfer" tells us
that
>name servers that belong (in a technical sense) to the zone of a domain are
>also transferred to the new owner. This implies that the ownership of name
>servers is related to the ownership of the corresponding domain. Now the
>problems start:
>
>  - may have name servers a different owner than the domain they belong to?
>
>  - if not, may other registrars have the ability to register a name server
>    that belong to a domain sponsored by another registar? Is the ownership
>    automatically transferred to that registrar just after registration?
>
>
>One big problem we regularly have with NSI's current registry system is
that
>it disallows the registration of a name server belonging to a domain
>registered by another registrar. The requirement to be able to do that
might
>be unreasonable in the first view. But many customers choose to use
multiple
>registrars simultaneously for registering their domains, and it is rather
>difficult to explain to them that we can't register their domains with name
>servers they had specified and they own. It is a serious flaw in the design
of
>the current system and should be avoided in any new protocol.
>
>Therefore, the requirement document should detail the question of ownership
>and restrictions regarding it. 
>
>Scott, could you please describe how you envisage the behaviour? 

The draft doesn't use the term "ownership" anywhere, and for good reason.
What "ownership" means depends on legal definitions that vary from place to
place, and I want no part of trying to determine how different entities
interpret the term.

"Sponsorship", on the other hand, describes the relationship between a
client and the objects the client creates in the repository.  The client
that creates an object has administrative rights to manage the object in the
repository.

I don't see a requirement anywhere in the draft that says that only the
registrar who creates foo.com can create hosts in foo.com.  Maybe that's a
hole, because 3.4.5 does say that if foo.com is transferred, all of the
foo.com hosts are transferred as well.  I don't think foo.com hosts should
be transferred unless they are all sponsored by the same registrar.  Without
this requirement, the other alternative is to change 3.4.5-[1] to remove
everything after the first sentence and go back to the drawing board to
figure out how to deal with host transfers.  If the list really supports the
idea of allowing any registrar to create a host object, then we also need to
support explicit host transfers.

As currently written, 3.4.5 says that name server sponsorship relations must
be maintained when a domain is transferred.  If foo.com is transferred, all
of the foo.com hosts are transferred as well.  If we assume that no other
registrar can create hosts in foo.com, a consistent sponsorship relationship
is changed when a domain transfer takes place.  3.4.9 says that the list of
name servers that are subject to transfer must be visible as part of the
information describing a domain, so there's no surprise or hidden
relationships.

Now, one can argue (and we have, we've talked about this more than once)
that this is a restrictive model, and that any registrar should be able to
create a host in foo.com.  As I've said before, this introduces a different
set of difficulties regarding management of foo.com that I believe are more
difficult to solve.  Once you have multiple registrars creating objects that
are hierarchically related to foo.com the registrar of foo.com doesn't have
a complete picture of the domain object, which may lead to inter-registrar
(that is, _competing_ registrar) coordination requirements and associated
problems.

<Scott/>