Re: Changes we'd make to EPP

I completely agree with the balance you are talking about. No one wants to
meddle lightly with deployed systems.  However, maintaining
standardization means (I think) keeping a protocol relevant to the use
cases that evolve.  We are talking about addressing bulk communications
around an EPP object in this case - so I think its fair enough to consider
short-comings in the protocol.  EPP probably should have had more focus
right from the start in addressing bulk operations.

However, that thought aside, I still think that one could probably address
the abandoned contact use case with an extension approach BUT I would
really want to see that particular extension be standardized.

There are always going to be 2 camps in these discussions, those who are
more than willing to update existing EPP systems with newer protocol
versions/features because they achieve a net benefit, and those whose
existing implementations do a good enough job and don't want to incur the
cost or anticipated risk.

It's a balance between the two positions, always, but I think its safe to
say we had better be prepared to work on the next iteration of EPP.  There
are a lot of new use cases coming down the pipe, as well as a backload of
ccTLD use cases.  If we don't address these, the protocol will eventually
become irrelevant and after all the good work done here, I think it would
be a shame to let it's usefulness erode.

Ok done preaching for tonight.
  

-M


On 12-01-17 7:25 PM, "Andrew Sullivan" <[email protected]> wrote:

>On Tue, Jan 17, 2012 at 04:38:48PM -0600, MICHAEL YOUNG wrote:
>> That leaves you with out of band, why is that better?
>
>Perhaps because EPP is badly tailored for bulk operations.  I can
>think of ways in which it might have been otherwise, but the WG
>decided not to go that way.  Since the protocol is poorly adapted to
>such operations, why try to force them in there?
>
>Or, put it another way: EPP is by no means the only relationship
>between an EPP repository operator and the clients: much of the system
>depends on pre-existing relationships anyway.  Therefore, it seems at
>least as good to use those other communication channels for bulk
>operations as to add features to EPP for this.  I am not saying that
>it is better or worse; but that there are other options, and before
>one is going to change deployed systems to deal with new desired
>behaviour, one needs an argument that alterations to those deployed
>systems is the right approach to satisfy the desire.
>
>A
>
>-- 
>Andrew Sullivan
>[email protected]
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg


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