Discussion in 'Nominet General Information' started by FC Domains, Aug 1, 2006.
I base my comments on dropcatchers only regging domains that drop.
I'm not sure we are all talking about the same thing here, so I'm going to try and make sure we are all on the same page.
The process is
1. You register a name
2. It is not invoiced until the 8th of the next month.
3. Until then you can delete it for free.
4. After invoice you can still delete it, but you will still have to pay for it.
5. Once the domain is paid for, only the registrant can delete it by going through our surrender process.
Now what some people are doing is
a. register name
b. put on PPC site
c. monitor revenue and if it does not look like it will make enough then cancel before 8th of next month.
and it is that which we are saying is an abuse of our systems. In .com around 98% of all reigstrations are just tasted in this way. If this really took off here then it could mean a massive increase in load on our Automaton, with only the smallest revenue increase (those that were not deleted).
None of those are mistakes. They are business risks that you have taken.
That sounds like a mistake.
Being firm can be seen by some as aggressive, but not by others. This is a practice that has started in .uk and we need to stop it in an unambiguous fashion.
92.3% of .coms are "domain kited" each month (32 million domains). Where the person registers the domain, keeps it for 4 days 23 hours (the limit on .com is 5 days that you can delete). The domain is then dropped and re-registered immediately, kept for another 4 days 23 hours, repeat repeat etc.
The domains are NEVER paid for ...
"Domain tasting" is very different . . .
After the limit is reached you will not be able to delete any more uninvoiced domains.
But let me reiterate, the limit on tasting is zero. The limit is there to help us identify potential abuse.
To be fair, that is the percentage that are not paid for. The proportion kited or tasted is a moot point. As far as we are concerned they are both unacceptable.
Now I'm bashing my head against the keyboard. Let's see how simple I can make the question.
If I have registered a domain name that I will have to pay for anyway, why can't I delete it?
Might be talking rubbish, so correct me if I am wrong. I was told by registrant services quite a while back that once invoiced you can still delete it but you will have to pay for it. Once the payment has been made and the status changes to regged until renewal date then it has to be surrendered.
Colin just wait to after the 8th.
Good point, but the rules imply that those will count as well.
I know the feeling.
If the domain has been invoiced then you can delete it, you will still have to pay for it and there are no limits on the number you can delete.
If the domain has been paid for then only the legal registrant can have it cancelled through our surrender service. The tag holder cannot delete it through the Automaton. In the corner case where the TH and registrant are the same the problem is that the Automaton has no way of knowing if the tag holder is the registrant.
That's all I wanted to know and the email from Nominet didn't say this.
Here's an idea then. How about you allow the a TAG name as the registrant.
That way automation would know.
Then maybe the TAG holder would be allowed to change the registrant field using 'edit'. All perfectly secure.
First, our new account structure, when completed, will let us know when the TH == Reg. You will have seen the first phase of this if you have logged in to the new online service.
Second, we do not allow tag holders to change the registrant field. Registrants have to come to us and follow the transfer process.
YES I KNOW THAT, but if the resistrant and the tag hold are the same person, why shouldn't the tag holder change the registrant through automation.
To make this simple, the tag holder could just put his tag in the registrant filled when registering the domain. Automation would then know and it would be secure.
Do I need to be expessing ideas more simply?
Good idea will save time............
Because we want registrants to use our transfer process, which has more to it than just changing one field. We don't want the registrant field being changed through the Automaton.
Tell me about it!
So it's the £30+VAT then.
Seeing an increasing number of obviously speculative registrations that are dumped before pay day I think it is a very good idea - or else we will end up with a situation like the .coms.
I have deleted a few names that I registered by mistake - typos due to late nights! - but don't see any problem with the new rule.
I think FC has a good idea and just saying "...because we want registrants to use our transfer process..." isn't addressing the idea. If you're wanting to protect your transfer fee income say so.
Actually it is, and here I go running the risk of being flamed again, but I'll explain anyway.
The answer Jay gave is Nominet's official position; Nominet wants registrants to use its transfer process. This has very little to do with "wanting to protect transfer fee income" because the fee is set at cost recovery, not at a profit margin. Maybe the fee is wrong, but that is an operational (costing) issue for Nominet to consider. Perhaps in the future, tag holders may be allowed to electronically change the registrant field, but whether people like it or not, Nominet has a right under company law to protect its systems and a right to apply its Tag Holding rules equally to all tag holders.
As an aside; there were 2,902 active members and 3,922 active tags at 31st May 2006. It seems, from what I've seen so far, that the majority don't see too much wrong with this rule change. The way I see it is this. Nominet cannot set its rules to cater for a handful of members or tag holders, it has to set its rules to protect the integrity of its systems and the majority of its members and tag holders. If it doesn't pre-empt the 'kiting' phenomenon in the .com domain, pretty soon we'll see the same levels of misuse of the system as in the States. If that happens, it will be a small minority compromising the integrity of the system to the detriment of the majority.
Acceptable Use Policy here.
Separate names with a comma.