Re: Registry lock - two-factor or intervention

> If you have an automated system, why implementing something else than EPP?

Different reasons in different use cases, but really non EPP APIs (I think anyways) come into play when you are dealing with arm's length associated actions or decisions that in turn trigger a core EPP call.

For one example, some registries are heading towards stronger identity verification, where the registrant must be examined by a third party (to both the registry and registrar) before a registration is allowed to be finalized.  I use the word finalized carefully, because while that verification occurs, one could using a pending create or one could also combine a typical registration with all the server prohibited statuses applied.  When the verification process is successfully done, a core EPP command then results in the registration going to a "regular" state - whatever that happens to be for that particular registry.

Registry Lock really is a product that happens to entail more than just firing a core EPP command, there are elements of identity verification, two party involvement, etc, all of which really happen outside the registry.  The final result of all that activity is that a core EPP command is triggered to apply Server prohibited statuses or to remove them.  During most of the lead up process, I have no real need or desire to talk with an EPP server, just at the end of the decision making.

The actual functionality of an EPP Server is relatively straight-forward, when you think of comparative large systems, which a really good thing in an infrastructure system.  I think if we are to hope to successfully standardize extensions, we should be critical of which elements of proposed extension use cases really need to involve an EPP server, and which are better served as an external system.

That said, don't get me wrong, I'm all for standardization whenever we can achieve it.


MICHAEL YOUNG
[email protected]

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg