On 17 Jan 2020, at 7:21, Patrick Mevzek wrote: > If you look at what happens in the wild, you can come to the conclusion that > there is probably no proper way to handle it in EPP... as many registries > with this need do things in very different ways:
Hi *, I agree with Patrick here, there are other tools the RY can use to handle situations like this. In our EPP implementation we have some *reasonable limits* configured to deal with this type of situation, if the client is triggering a >=2000 error code and will continue to send the command, we basically delay the response as Patrick mentioned. We’ve had a few interesting situations that we’ve observed. We had a registrar that was sending thousands of (epp `<hello />`) commands per second, this wasn’t affecting us as the `<hello>` processing doesn’t require a lot of work, but once we detected it, a simple conversation with them was able to detect and fix a problem with their client implementation. We have another situation where the client is sending a broken EPP `hello` command, triggering a syntax error, but that itself resets the timeout ticker, so they never notice it. We’ve contacted them about it and hopefully they’ll fix it. Sending an *error* code requires the client to implement some sort of rate-limiting awareness making it non-trivial, whereas a delayed server response is handled automatically in most cases. Best, Francisco Obispo VP - Technology -------------------- Uniregistry 400 Spectrum Center Dr. Office 1660 Irvine, CA 92618 Office: +1 949 706 2300 x4202 fobi...@uniregistry.link
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
