Re: Nameserver as object/entity or not ?

[George Belotsky <george@register.com>]

As can be seen from Jordyn's post, domains can be treated as objects
and still maintain the policy semantics that Catherine finds
desirable.

Once again, it is important not to confuse policy and mechanism.  In
an object oriented system, attributes of objects may be objects in
their own right.  This is a design issue that is part of the
mechanism.

We are unlikely to totally agree on a set of policies.  Policies will
also change over time, and will be influenced by many factors --
including legislative choices made in various jurisdictions.  Members
of this group can hope to have some input towards such legislative
choices, but will almost certainly not be in a position to make them.

It would thus be helpful to identify the policy problem space, rather
than try to finalize detailed policy decisions.  By correctly
identifying this space, we will build something long lasting and truly
valuable -- something that can outlive the policies of today and adapt
to the policies of the future. 

George.


On Thu, Feb 08, 2001 at 12:58:35PM -0500, Jordyn A. Buchanan wrote:
> At 10:57 AM 2/8/2001 -0500, Catherine Murphy wrote:
> 
> >IP registries are a case in point. While I can see where some domain
> >registries will want to treat nameservers as objects, we can not. The
> >nameserver information that ARIN receives for in-addr nameservers is an
> >attribute (or dependent object) of the IP network object. Kent's point of
> >potentially conflicting ownership/authentication would also hold true for
> >us. Since we are receiving the information from a particular network
> >registrant, the nameserver information only extends to the scope of his
> >authority, i.e., that network. The same nameservers could quite possibly
> >be listed for other networks, but the authority to change a nameserver is
> >limited. There is not inherent "ownership" of the nameserver information.
> >If both Network A and Network B list ns1.foobar.net as its in-addr
> >nameserver, Network A could not come to us and say, change all instances
> >of ns1.foobar.net to ns2.foobar.net. Rather, it could only affect that
> >change against its network; ns1.foobar.net would remain on network B.
> 
> I think that there are two separate issues here:
> 
> 1) Should name servers be treated as objects or as attributes of other objects?
> 
> 2) If nameservers are objects, how do we manage ownership of these objects?
> 
> Issue #2 seems to me to be mostly a matter of registry policy.  Some 
> registries may want to say that the owner of a domain implicitly owns all 
> nameservers within that domain.  Others may not, but may want to verify 
> that the owner of the domain approves of someone else having a nameserver 
> in their domain.  Others may not care at all.  The requirement should be 
> for an approach that accommodates these various policies.
> 
> If we look at our objects as being "pointers to nameservers" with the 
> possibility of multiple pointers to the same actual nameserver, I think we 
> can achieve a solution that achieves many of the benefits of the 
> nameserver-as-object approach without the inherent ownership issue.  Such 
> an approach allows a registrant to use a common name server object across 
> many domains (or IP blocks), but doesn't imply that the registrant "owns" 
> the name server or that changes made to the object changes the name server 
> for other people.
> 
> For example, both BigISP and SmallCo may use BigISP's nameserver, 
> NS1.BIGISP.NET.  BigISP creates an object in the database pointing to the 
> nameserver and names it "NS1-BIGISP".  SmallCo has a lot of domains and 
> realizes that they may want to get their own name servers later on, so they 
> create a new object pointing to the same nameserver and call it 
> "NS1-SMALLCO".  Later on, SmallCo does in fact get their own nameservers, 
> so they point "NS1-SMALLCO" at their new nameserver, 
> TINY.SMALLCO.COM.  This allows them to modify the nameserver information on 
> all of their domain names by making a simple modification to the nameserver 
> object, and doesn't affect BigISP's use of NS1.BIGISP.NET in any way.
> 
> If registries or registrars want to make each nameserver an attribute of a 
> domain that doesn't apply to any other domains, they can simply create a 
> new nameserver object for each domain.  This is slightly inefficient, but I 
> don't know why this is a desirable goal in and of it self in the first place.
> 
> >We also differ in that we will be tracking no other data about the
> >nameserver except for the nameserver itself, e.g., ns1.foobar.net.
> >(Currently, we receive the IP address of the nameserver, which is
> >displayed in whois, but is not used to produce glue records. Since we are
> >not authoritative for these nameservers, it does not make sense for us to
> >maintain the IP address.)
> 
> This is already dealt with by the existing requirements.  The IP address of 
> a name server is only required (indeed, is only allowed) if the name server 
> is "registered within the registry's authoritative TLDs".  So, only the 
> .NET registry needs to worry about the IP address of NS1.BIGISP.NET.  In my 
> scheme, we'd only want one version of the name server to actually have an 
> IP address to avoid states where multiple pointers have the same name but 
> different IP addresses.
> 
> Jordyn
> 

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