RE: [ietf-provreg] Comments: draft-sullivan-epp-experience

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

> -----Original Message-----
> From: owner-ietf-provreg@cafax.se 
> [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan
> Sent: Tuesday, August 16, 2005 10:58 AM
> To: ietf-provreg@cafax.se
> Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience

[snip]

> The "linked" status doesn't strictly prohibit deletion itself;
> instead, 3732 has this: "A host name object MUST NOT be deleted if
> the host object is associated with any other object."  Similarly, 3733
> has this: "A contact object SHOULD NOT be deleted if it is associated
> with other known objects."  I can see an argument for preserving the
> latter; but the former is surely a policy decision, and ought to be
> left to the repository operator.
> 
> I realise that this proposal may be more controversial than the one
> to unhook the prohibitiond from the "pending" states.  But even
> though this is expressing a policy that is a good idea -- don't allow
> deletions of an object if anything else refers to it -- it's still a
> policy, and therefore something that a repository operator might want
> to change in some circumstance we haven't imagined yet.  Since the
> prohibitions are already possible using some other status, there's no
> reason to use this status to enforce the prohibitions.  (I think the
> linked status is worth keeping, because one might use it as the basis
> of policy.)

While I agree that this isn't a protocol interoperability issue,
remember why the text is there: deleting a host object (or a domain
object that has subordinate host objects) has the potential to *BREAK*
DNS resolution.  Some poor operator that's not a party to the
registry-registrar relationship doesn't find out about such changes
until something disappears from a zone and things stop working.

I'm not averse to softening the MUST NOT to a SHOULD NOT as long as we
explain that things can really break if it's done without consideration
of object relationships.

-Scott-