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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 15 Aug 2005 09:05:14 -0400

Thanks to the guys from Afilias who took the time to write
draft-sullivan-epp-experience.  This is exactly the kind of info we need
to discuss to determine what the next steps should be with the protocol.

As described in the intro, the document covers four things.  My take on
each, in order:

1.  The creation of the "Redemption Grace Period" (supported under EPP
by [RFC3915] requires that certain provisions of [RFC3731] be violated
in order to offer the new service.

I believe we've already talked about removing the "update prohibited"
restriction from 3731.  My intention with 3915 has always been that
actions to take a domain out of a "pending" status could over-ride the
restriction.  I agree that this isn't clear, and 3731 needs to be
updated.  Here's the text that should be removed from section 2.3:

"With one exception, transform commands MUST be rejected when a
pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or
pendingUpdate status is set.  The only exception is that a <transfer>
command to approve, reject, or cancel a transfer MAY be processed while
an object is in "pendingTransfer" status."

There's similar text in the host and contact mappings.  They should also
be updated to remove this text.  If a registry wants to prevent updates
during one of the "pending" states, it can do so by explicitly setting
one of the "prohibited" status values.

2.  Experience with implementation suggests that status values may be
insufficiently granular.

I will argue that granularity is a prime example of something that is
tailor made for extension development.  The protocol defines some basic
capability.  That capability can be expanded using protocol extensions.
It's exactly why the extension mechanism exists.

3.  Experience with the poll queue mechanism suggests that a more
sophisticated mechanism might be useful, or that the requirements for
implementation should be relaxed.

We started talking about this last week.  I agree that the text in 3730
needs to be relaxed.  I've suggested that new functionality may be best
addressed as part of an extension.  Others may disagree.

4.  Experience with <update> commands suggests either that status values
are too coarsely-grained, or that another set of commands entirely needs
to be defined.

Same argument from me as used in point 2.  Needed granularity implies
extension candidacy.  The question, of course, is breadth of appeal.  We
should talk about it if others think that more granularity should be
added to the core.  We should defer to an extension if the appeal is
limited.

-Scott-

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Aug 2005 09:37:54 -0400

Hi Scott,

Thanks for your comments.  I particularly like this one:

> added to the core.  We should defer to an extension if the appeal is

That's exactly the feedback I've been hoping for.  If there's broad
consensus that the proposals are ill-conceived or not general enough,
I think that the extension mechanism is the way to go, also.

Thanks much,

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Aug 2005 10:58:26 -0400

In my response to this, I forgot to mention one other thing.

> updated.  Here's the text that should be removed from section 2.3:

[. . .]

> one of the "prohibited" status values.

I've also ended up arguing that the "linked" status should be
similarly unconnected to prohibitions.  The general idea is that if a
repository operator wants a policy prohibiting some action or other,
then the operator should place such a prohibition on the object. 
Nothing else should entail such a prohibition.  

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.)

Thoughts?

A

----