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

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

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-