RE: Handling of External Host Objects

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

> I assume that with the new external host approach domain 
> transfer process would
> be simplified. No error code 2305 for transfer requests and approvals.

It's premature to call what I wrote below "the new external host approach"
(it's still just a re-issue of a proposal that I'd like people to consider),
but yes, with this model there would be no need for object management errors
on transfers as currently described because there would be no need for the
per-registrar copies of external hosts.  An external host attribute would
just get carried along with all other domain object attributes.

-Scott-

> Regards,
> 
> Janusz Sienkiewicz
> 
> "Hollenbeck, Scott" wrote:
> 
> > One of the reasons I think that this external host thing 
> continues to be an
> > issue is because it's a kludge.  I firmly believe that the 
> only objects that
> > should exist in a repository are objects for which the repository is
> > authoritative.  Other needed data should exist as 
> attributes of existing
> > objects.
> >
> > I suggested this concept related to external hosts back 
> when the topic first
> > came up.  Some folks had issues with it, but I'll suggest 
> it again as an
> > alternative.  In a nutshell:
> >
> > - The only objects that should exist in a repository are 
> objects for which
> > the repository is authoritative.
> >
> > - Host objects should only be created in a repository that 
> is authoritative
> > for the host.  In the case of hosts as name servers, 
> "authoritative" means
> > that data in the repository (host name and address(es)) is 
> used to publish
> > DNS glue and the repository is the legitimate source for that data.
> >
> > - If an external host is needed for delegation purposes, it can be
> > associated with a domain object as an attribute of the 
> object with no host
> > object needed in advance.  There's no need to create an 
> external host object
> > ahead of time, no need to worry about IP addresses, etc.
> >
> > This solution does not allow object-based management of 
> external hosts,
> > which means that renaming the external host would need to 
> be done on a
> > per-name basis.  It may address the other issues that 
> people have talked
> > about on this thread, though.
> >
> > I know this means that a domain can be associated with 
> hosts as objects and
> > host as attributes and some people think that's 
> inconsistent.  I don't think
> > it is if you agree with the first point above.
> >
> > -Scott-
>