Re: [ietf-provreg] EPP Document Updates

[Andrew Sullivan <andrew@ca.afilias.info>]

On Fri, Jul 22, 2005 at 07:20:26AM -0400, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: janusz [mailto:janusz@ca.afilias.info] 
> > >
> > Will removing transform restrictions on pendingDelete remove all 
> > conflicts between 3731 and 3915?
> 
> It will if the registry doesn't do something stupid to introduce a
> potential conflict.
> 
> > Lets consider a scenario when a deletion policy prohibits any 
> > updates of 
> > domain objects between enetering pendingDelete state and rgp restore 
> > request. If serverUpdateProhibited status is used then rgp restore 
> > request should not be accepted because it is an extension of <update> 
> > command. From the other hand I don not see any mechanism within EPP 
> > protocol to protect the domain object from client updates and at the 
> > same time allowing <update> requests with rgp restore extension.

It seems to me, though, that Janusz is pointing to another difficulty
that I've also noticed: the *UpdateProhibited status values are too
coarse.

I understand the value of consistency: we have one type of
prohibition against (for instance) <domain:delete>; so we should
similarly have one type of prohibition against other commands, like
<domain:update>.

The trouble I have with this is that <domain:delete> really has only
one function: either it causes a delete to be initiated (and maybe
completed) against a domain, or it does not.  It therefore makes
sense that a client or repository should either prohibit deletes, or
not.

In contrast to that, <domain:update> can change all manner of
attributes on a domain.  Moreover, there are certainly cases where we
want one update to be possible, but not others.  Afilias has had
cases where we wanted (for example) to prevent contact data
associated with a domain from changing; but that didn't mean we
wanted nameserver information not to change, or that we thought it'd
be a bad thing for people to be able to update their authInfo to
something slightly more tough to guess than "1234".

I wonder if the answer is to make some of the update prohibitions
more granular?  I know it's sort of ugly, but it's consistent with
the use-cases we've actually seen.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
                                        +1 416 646 3304 x4110