Re: clTRID element clarification

On Thu, Mar 1, 2012 at 5:11 PM, Ulrich Wisser <[email protected]> wrote:
> We actually do have registrars not sending clTRID at all, sending the same
> clTRID with every command, sending the clTRID from our example code with
> every command, setting clTRID to a hash of the command, ...

I periodically bring up the idea that we ought to consider putting a
unique constraint on clTRID on a per-registrar basis; in principle,
that ought to be someone a registry could consider imposing as a
policy.

Nobody gets terribly enthused about that idea.  They expect, and I
think they're right, that this would irritate registrars that are
using particularly lazily-constructed client trids.

Furthermore, it does not seem likely that there would be huge value to
be gained from doing a lot of work interpreting clTRID values.

It's an interesting idea to put an object cache that uses client trid
as the basis for identifying that two requests ought to be interpreted
the same way.  But that seems likely to be counterproductive, looking
at a couple of cases:

1.  To repeat a write operation seems likely to cause trouble.
Re-requesting a domain renew shouldn't be able to work, for instance,
as two separate renew requests will need to be different as they need
to include different expiry dates.

2.  Caching read operations means that registrars are getting
increasingly stale data, and if they were doing a domain check to see
if a domain has become available, there's a risk that they are getting
*wrong* information.

So, the idea is interesting, in some theoretical ways, but in the
absence of something *really* valuable to gain, I don't think it's
worth irritating registrars by imposing a bunch of logic onto the
interpretation of clTRIDs.

Making some operations a little faster doesn't seem to be worth the
potential for irritation.
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg