Robin Hood

[mreeves]

Thanks Jay.

 

[Jay Daley]

However, on a slightly different topic, the internal Nominet policy sounds a bit 'human'. - i.e. a senior person deciding what should be dropped that day at 23.50 at night.

This only relates to prenoms, which are very few in number and not the same as the ordinary drops that are activated by our renewals system. There are few other reason for manual cancellation but again the numbers are very small.

I am sure that Nominet is as honest as daylight, but I am almost equally sure that that senior person is under no written obligation not to forewarn anyone he chooses prior to his decision, a bit like insider trading but completely legal. (in some countries insider trading is legal anyway.)

We do have rules about confidentiality and everyone who works here and has any form of access to manual cancellations understands those very clearly.

 

[FC Domains]

Nobody mentioning cheating, until somebody jumped up in defence when nothing had been said.
This topic was all about coming up with a better scheme that the current best.

However there is a problem, that you can currently gain advantage because the current system isn't operating as publicised.
1) For example, DAC is more often than not beaten by a speculative request in the Automation queue.
2) Drops are a very long way from being random.
3) There are also a number of tricks to manipulate Nominets servers. Some of which deviate from RFC standards, which is useful if you know how.
4) The automation queue has to go.

The point is that you could deduce the above, which isn't cheating. It just looks like.

 

[paul]

1) For example, DAC is more often than not beaten by a speculative request in the Automation queue.

If this is indeed true the best way to fix it and make fairer system would be to drastically reduce the number of speculative emails people are allowed to send.

This is from the nominet site:

In the past we have experienced persistently large volumes of REQUEST or QUERY operations for domains that are already registered and on another tag. This behaviour is causing the following problems:

• delays for other automaton users
• significant mail congestion in the automaton mail queues as the automaton replies are sent at a higher rate than can be accepted by the tag holder’s mail gateway.
• large volumes of effectively unnecessary log file entries per day
• the cost of building an infrastructure larger than required
• unnecessary work for the automaton leading potentially to a greater exposure of the automaton to faults

The system already allows you to send 1000 speculative emails for names already registered. This could be improved in a number of ways IMHO

1. No more than one request per name per day (or maybe 1-5 requests)
2. Restrict the number of requests for suspended names to a much lower quota but keep requests for domains that aren't suspended higher so as not to penalise people who have systems that are just too slow


Paul




Local Shops Adult DVDs HPI Check Domains

 

[Jay Daley]

Some interesting things here that I would like to follow up.

1) For example, DAC is more often than not beaten by a speculative request in the Automation queue.

How do you know that? When the DAC first started that was certainly the case but I don't know now so I'm surprised anyone else does. One of the interesting things I notice is that individuals get a fairly distorted view of how the this all works and we at Nominet only see the full picture when we run aggregate stats.

2) Drops are a very long way from being random.

Any evidence at all as to why you think this would be appreciated. Otherwise this just sounds like FUD.

3) There are also a number of tricks to manipulate Nominets servers. Some of which deviate from RFC standards, which is useful if you know how.

If you could let me know about those privately then again I would appreciate it. In particular where you think we deviate from RFCs.

4) The automation queue has to go.

I don't get this?

 

[retired_member9]

Any evidence at all as to why you think this would be appreciated. Otherwise this just sounds like FUD.

Why drops aren't really random:
as I said in previous thread, on 5 Dec, about 20-30 prenoms were deleted between 23.50 -- 00:05 am of 6 Dec.

 

[FC Domains]

Some interesting things here that I would like to follow up.

I've replied by PM

 

[Jay Daley]

Why drops aren't really random:
as I said in previous thread, on 5 Dec, about 20-30 prenoms were deleted between 23.50 -- 00:05 am of 6 Dec.

Random means random not evenly distributed. Given the volume of complaints that the drops are not random I will have them checked out but behaviour like this above is to be expected with random drops.

 

[retired_member9]

Thanks for comments!..

I remember you once mentioned that "even Nominet staff can not know exactly when domain drops", but it seems with the prenoms it's not the case, as sometimes time frames can be so limited?

After the day was choosen and "red button" pressed, why don't you utilize the same trully random algo as you do with the normal names? To distribute them evenly during, say, next 24 hours.

Wouldn't that help avoid complains?

I bet it would, as if you can get rid of "human factor", why maintain temptation?

 

[keys]

Thanks for the discussion of this subject both here and elsewhere.

The picture is clearer now. There is no evidence of foul play, and I have received an acceptable explanation of the strange drop results. It is not appropriate to say any more and I would have no objection if Admin wish to lock the thread.

 

[Admin]

Keys, we have no intention of locking this thread.

 

[brendan]

random?

Hi Jay,

I am new here, but I fail to see how you can argue that 20-30 names being dropped in a 15 minute period is randmoisation in action. Perhaps if there are 1000 names being dropped in that batch it is possible. If the procedure is random some kind of even distrubution would be expected as the population grows.

We have just registered for the DAC and with one query per 0.4 seconds if I evenly distrubute or 1 query per 0.12 seconds on a burst it is important for me to know that there is no increased likelyhood that I should burst my query rate as soon as I spot a prenom drop in the theory that random is not random as in evenly distrubuted if left long enough. At nominet is it a clumpy kind of random that only some dropcatchers know about and burst their scripts when they feel the first dollop hit the DAC.

Could you give some more clarity on the procedure for prenoms. I second vizzy's suggestions which seem like the only sensible course of action.

Brendan