Re: Handling of External Host Objects

[janusz sienkiewicz <janusz@libertyrms.info>]

I am not a big supporter of external hosts management per client basis.
By allowing limited mass domain updates on external host name change, the
feature makes epp client implementation easier. Unfortunatelly it makes
epp server implementation harder because it imposes asymetric treatment
of hosts objects (internal, external) across the whole system.  As
the thread shows it also complicates domain transfer implementation for
both epp client and epp server.

To alleviate the problems mentioned above let me propose the following
changes
to epp host and domain mapping documents:

Remove the text from host mapping document page 3:

  External host objects MUST be managed on a per-client basis.  No
  superordinate domain object exists in the repository, thus no single
  client has management authority for the superordinate domain object.
  Per-client management ensures that no single client can create an
  instance of an external host object to the detriment of other clients

Modify the text in  host mapping document page 18

  Host name changes MAY have an impact on associated objects that refer
  to the host object.  A host name change SHOULD NOT require additional
  updates of associated objects to preserve existing associations.

to

  Host name changes MAY have an impact on associated objects that refer
  to the host object.  In most situations a host name change SHOULD NOT
  require additional updates of associated objects to preserve existing
  associations. The only exception is external host name change for a host

  object that has associations with objects that are sponsored by a
different
  client. In such situation an EPP error message MUST be returned with
  error code 2305 ("Object association prohibits operation").

Remove the text from domain mapping document page 3:

  DNS domains can be delegated to external hosts.  If a domain has been
  delegated to an external host, a client MUST have created a host
  object for each delegation to an external host before requesting a
  domain transfer.  A transfer request or approval MUST fail with EPP
  error code 2305 if host objects representing the external hosts are
  not managed by the requesting client at the time a transfer request is
  made and at the time the transfer request is approved.


The changes above, unless I made a mistake or ommited something, should
result in the following
behaviour:

Mass updates on host name changes are allowed with one exception. If the
host is an external host
an error is returned if the host has associations with objects (domains)
sponsored by other clients.
If such situation occurs the client has still a way to provision the
change by creating a new external
host with the new name and updating affected objects sponsored by the
client.
Yes, it is imposing a limitation on "mass update" on external host name
change. In my opinion there
are benefits that justify the limitation. The two most important benefits
are:

No external host management per client basis is required.
Domain transfer request and approval process is simplified.

I know it is not a perfect solution but in my opinion it may be a
reasonable compromise for epp client
and server implementation.

Janusz

"Hollenbeck, Scott" wrote:

> > >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 see how this could resolve/avoid a lot of potential problems
> > (transfers, ownership, etc), but with these new gTLDs, I would guess
> > that the majority of nameservers in use are non-authoritative to the
> > registries, so registrars would lose the ability to do mass
> > updates as
> > with nameservers as objects.  I don't think I would want to give this
> > up.  As a registrar, I would have to write scripts to perform mass
> > updates, taking up processing time on both the client and the server
> > systems.
>
> Which puts us right back where we started with this discussion... ;-)
>
> -Scott-