RE: EPP Document Updates

"Hollenbeck, Scott" <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <046F43A8D79C794FA4733814869CDF07B5EEF3@dul1wnexmb01.vcorp.ad.vrsn.com>
> -----Original Message-----
> From: janusz [mailto:[email protected]] 
> Sent: Thursday, July 21, 2005 4:10 PM
> To: Hollenbeck, Scott
> Cc: Andrew Sullivan; [email protected]
> Subject: Re: [ietf-provreg] EPP Document Updates
> 
> Hollenbeck, Scott wrote:
> 
> >I agree that the transform restriction seems to be kludgy in and of
> >itself.  The protocol already includes features to prevent 
> transforms,
> >if desired by the registry, by adding status values as 
> Andrew suggests
> >above.
> >
> >In short, I believe that the right thing is to remove the 
> "pendingDelete
> >prevents transforms" restriction from 3731.
> >
> >
> >  
> >
> 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.
> 
> The "conflict" I described is not as severe as the original 
> one but it 
> can be treated as an inconsistency between 3731 and 3915 
> documents. The 
> inconsistency could be removed if rgp restore was defined as 
> a new EPP 
> command versus an extension to <update> command.

Yes, a new EPP command could prevent this scenario.  Unfortunately, it's
inconsistent with the guidance presented in RFC 3735.  If we're going to
modify both 3731 and 3915 (and I'm suggesting that we should) we have an
opportunity to write text to ensure that the protocol and the
ICANN-defined policy are consistent.

-Scott-
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.