Re: Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt

On 06/01/12 18:58, Andrew Sullivan wrote:

> On Fri, Jan 06, 2012 at 06:17:20PM +0000, Keith Gaughan wrote:
>> Another thing I'd change is provide a way for registries to signal to
>> registrars that they've garbage collected contacts (and possibly hosts too).
> 
> This, at least, ought to be possible using the poll queue.

Myself and Gavin Brown were chatting about this before Christmas because
CentralNIC have big problems with their registrars creating large numbers
of contact objects and then not using them.

Solving it cleanly is actually suprisingly awkward. It's really something that
ideally ought to be on the contact mapping (and possibly the host mapping
too). The extra message could be introduced as its own type of object (as some
registries have done for low balance notifications), but that's very much a
nasty and awkward way to bolt it on.

Alternatively, it could be done as an extension, which is less nasty and
awkward, but I've yet to come across a single instance of a message queue
message introduced as an extension, and thus chances are registrars would be
blindsided by poll responses with no response data, which could lead to a lot
of bleating[1] from registrars about having to re-engineer how they process
the message queue, even though it's something that's always been a possibility
according to the RFC[2].

I'm considering writing up an I-D for this, which is one of the reasons I
mentioned it.

> I think
> the poll queue as it stands is less than ideal, however.  I made a
> suggestion about how to make the poll queue better for these purposes
> in a long-expired draft (draft-sullivan-epp-experience-00), but they
> weren't very popular.

I read that a while back, and I remember not being entirely convinced by the
need myself. After all, there's nothing requiring messages on the message
queue from having a particular temporal ordering, and there's certainly no
requirement for message IDs to be monotonically increasing numbers. After all,
there's no requirement for it to be a FIFO.

Registrars who want to solve the problem could do so by using a priority queue
where queue ordering is based off of the time the message was placed on the
queue and a internal numerical priority assigned to it. The queue itself could
then be implemented as a binary or fibonacci heap[3], or some other
datastructure that might suit the registry's needs better.

K.

[1] Given I work for a registrar, I think it's safe for me to say things like
    this.

[2] I've experience of this from another mailing list I'm on from one
    registrar who couldn't understand one is only meant to send back the
    subset of supported objects and extensions they support that were
    mentioned in the greeting when they log in.

[3] The latter would seem to me to be the better all-round choice, though the
    cost of insertions and deletions to a binary heap could be lowered by only
    performing the heapify operations after a small number of pops (say three)
    and when there are medium- or high-priority messages to be placed on the
    message queue.

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg