I'll go ahead and assume I wasn't the last person to get this memo (courtesy
Lauren Weinstein's PRIVACY Digest):
https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/
It does seem that this is going to make life difficult for a bunch of pretty
normal business processes.
If you didn't know about it either... ask yourself why not.
Cheers,
-- jra
I've worked behind the scenes for more than one of these outfits. I can tell you that domain registrars are basically printing money. On the other hand, I've also been the victim of domain hijacking. I can tell you that the domain registrars involved were less than useless in reversing the obviously fraudulent transactions. They basically said "Not our problem. Deal with it."
That's on top of the other obviously unethical practices by registrars, such as seizing nonexistent domain names following a prospective buyer's whois search, sluggardly unlocking of domains, etc.
Something had to be done. Now it has been.
To the registers whining about this change:
Not my problem. Deal with it.
-mel beckman
Although I'm not a member of the WG that defined such policy, having seen
the many occasions where domain hijacks occurred, I'm totally fine with the
outcome. I only see real impact for "wholesale" registrars, like OpenSRS,
eNom and Endurance, since they have to figure out a way to be compliant
with policy without actually having contact with the registrants, and this
kind of problem will continue to haunt them as they just operate a way for
companies to operate in the gTLD market outside of its framework.
Rubens
Seems to me that the proper thing to be done would have been for Registries to deauthorize registrars on the grounds of continuous streams of complaints.
<devils advocate hat>
On what metric? Pure volume? Percent of registrations? type of complaint by
similar x/y?
</devils advocate hat>
there are 'lots of complaints' against some registrars, but if you have
~20% of the .TLD market you're prone to get more volume than a 1%er, right?
Also, this isn't REALLY the registrY's problem is it?
i love how icann makes avoiding blame so easy.
Seems to me that the proper thing to be done would have been for
Registries to deauthorize registrars on the grounds of continuous streams
of complaints.<devils advocate hat>
On what metric? Pure volume? Percent of registrations? type of complaint by
similar x/y?
</devils advocate hat>
By the terms the Registry sets in the Registry/Registrar Agreement and to which the Registrar agrees in order to sell the Registry's names.
there are 'lots of complaints' against some registrars, but if you have
~20% of the .TLD market you're prone to get more volume than a 1%er, right?
There's this concept called "normalization", e.g., complaints per 100 delegations or some such.
Also, this isn't REALLY the registrY's problem is it?
Depends on whether or not the Registry wants their TLD to be associated with spam/malware distribution/botnet C&C/phishing/pharming and be removed at resolvers via RPZ or similar. Ultimately, the Registries are responsible for the pool the Registrars are peeing in -- it's the Registry's namespace, is it not?
i love how icann makes avoiding blame so easy.
I love how people love to blame ICANN.
Regards,
-drc
(speaking only for myself)
As a customer of OpenSRS they sent us a notice about the change. The notice, and this page you linked, speak to their customer communication about policy changes.
To be honest, I just breezed the email message and noted that it seemed like a positive change (without knowing the reasons that prompted the change). We rarely update registrant information and rarely transfer domains. We also know our customers. I expect this will have zero impact on our day to day operations other than potentially preventing some hijackings (we have had some customers experience hijackings in the days when all it took was a fax on letterhead to NetSol to get your domain info changed).
>> Seems to me that the proper thing to be done would have been for
>> Registries to deauthorize registrars on the grounds of continuous
streams
>> of complaints.
>>
>>
> <devils advocate hat>
> On what metric? Pure volume? Percent of registrations? type of complaint
by
> similar x/y?
> </devils advocate hat>By the terms the Registry sets in the Registry/Registrar Agreement and to
which the Registrar agrees in order to sell the Registry's names.
ok, neat!
> there are 'lots of complaints' against some registrars, but if you have
> ~20% of the .TLD market you're prone to get more volume than a 1%er,
right?There's this concept called "normalization", e.g., complaints per 100
delegations or some such.
that's something I expected, yes... some rate that works out if I just
registrar for 10 domains vs 10million. cool.
> Also, this isn't REALLY the registrY's problem is it?
Depends on whether or not the Registry wants their TLD to be associated
with spam/malware distribution/botnet C&C/phishing/pharming and be removed
at resolvers via RPZ or similar. Ultimately, the Registries are responsible
for the pool the Registrars are peeing in -- it's the Registry's namespace,
is it not?
it's not clear, to me, that any of those hammers have real effect.
> i love how icann makes avoiding blame so easy.
I love how people love to blame ICANN.
but, they are the names and numbers authority, no? it says so in their
name.
Jay definitely said 'registRARS'. And yes, it *is* the registrar's problem
to ensure they aren't selling thousands of domain registrations to known
spammers and other miscreants.
Depends on whether or not the Registry wants their TLD to be associated with spam/malware distribution/botnet C&C/phishing/pharming and be removed at resolvers via RPZ or similar. Ultimately, the Registries are responsible for the pool the Registrars are peeing in -- it's the Registry's namespace, is it not?
it's not clear, to me, that any of those hammers have real effect.
Not sure the RPZ hammer has been brought out in force yet. I've seen a few recommendations on various mailing lists, but no concerted effort. Unfortunately, there is no easy/scalable way to determine who a registrar for a given name is, so the hammer has to be applied to the TLD as a whole, which has unfortunate side effects...
I love how people love to blame ICANN.
but, they are the names and numbers authority, no? it says so in their name.
"Internet Corporation for Assigned Names and Numbers" -- Don't see "authority" in that name. 
Regards,
-drc
(speaking only for myself)
Depends on whether or not the Registry wants their TLD to be associated
with spam/malware distribution/botnet C&C/phishing/pharming and be removed
at resolvers via RPZ or similar. Ultimately, the Registries are responsible
for the pool the Registrars are peeing in -- it's the Registry's namespace,
is it not?it's not clear, to me, that any of those hammers have real effect.
Not sure the RPZ hammer has been brought out in force yet. I've seen a few
recommendations on various mailing lists, but no concerted effort.
Unfortunately, there is no easy/scalable way to determine who a registrar
for a given name is, so the hammer has to be applied to the TLD as a whole,
which has unfortunate side effects...
it's a fun game of chicken 
There have been some actions taken by
registries in the past (I think .TK did this at some point) to try and make
their cone more clean/neat, for a time .science was also being abused but
isn't (today) anymore. Perhaps this all self-polices?
I love how people love to blame ICANN.
but, they are the names and numbers authority, no? it says so in their
name."Internet Corporation for Assigned Names and Numbers" -- Don't see
"authority" in that name.
I hate it when you are right
Not sure the RPZ hammer has been brought out in force yet. I've seen a few
recommendations on various mailing lists, but no concerted effort.
Unfortunately, there is no easy/scalable way to determine who a registrar
for a given name is,
That is called RDAP, but ICANN currently blocks gTLD registries from
offering RDAP.
Rubens
Rubens,
Not sure the RPZ hammer has been brought out in force yet. I've seen a few recommendations on various mailing lists, but no concerted effort. Unfortunately, there is no easy/scalable way to determine who a registrar for a given name is,
That is called RDAP,
I said "scalable".
Given RDAP is based on TCP and there is this concept known as "registration data lookup rate limiting", I'm somewhat skeptical RDAP is the appropriate choice for (e.g.,) a "DNS Block List"-like solution that would (say) dump email that came from domains registered via operator-specified registrars.
but ICANN currently blocks gTLD registries from offering RDAP.
Ignoring the above, and as I'm sure you're aware, the community has not determined the policies by which RDAP may be offered as an official registry service using production data, e.g., whether and how differentiated services will be permitted among other details. As such, it is more accurate to say that registries are not permitted to deploy new services because of contractual obligations the registries entered into that requires them to have new services evaluated to ensure those services don't impact DNS security, stability or competition, something the community required ICANN enforce as a result of the SiteFinder episode ages ago. Registries can, of course, request that evaluation and I'm told some have and are actually offering RDAP.
But I would agree it is much easier to simply blame ICANN.
Regards,
-drc
(speaking only for myself)
Perhaps this all self-polices?
I figure either it does or governments get involved and that most likely ends in tears.
I hate it when you are right
Don't worry: very rarely happens.
Regards,
-drc
(speaking only for myself)
> Perhaps this all self-polices?
I figure either it does or governments get involved and that most likely
ends in tears.
I can't wait for our gov't overloads to discover that they might be able to
regulate/legislate the internets... Wait, doesn't ICE already do that? Oh,
and also some Brexit oriented group as well?
> I hate it when you are right
Don't worry: very rarely happens.
see it's already not happening.
David Conrad writes:
> <SNIP>
>
> But I would agree it is much easier to simply blame ICANN.
>
Yeah, I always blame ICANN for the bad weather :-).
jaap
Rubens,
>> Not sure the RPZ hammer has been brought out in force yet. I've seen a
few recommendations on various mailing lists, but no concerted effort.
Unfortunately, there is no easy/scalable way to determine who a registrar
for a given name is,
> That is called RDAP,I said "scalable".
Given RDAP is based on TCP and there is this concept known as
"registration data lookup rate limiting", I'm somewhat skeptical RDAP is
the appropriate choice for (e.g.,) a "DNS Block List"-like solution that
would (say) dump email that came from domains registered via
operator-specified registrars.
Fair enough. There are though non-standard UDP-based domain lookup
implementations like isavail that could address both this use case and
provide faster availability searches.
> but ICANN currently blocks gTLD registries from offering RDAP.
Ignoring the above, and as I'm sure you're aware, the community has not
determined the policies by which RDAP may be offered as an official
registry service using production data, e.g., whether and how
differentiated services will be permitted among other details. As such, it
is more accurate to say that registries are not permitted to deploy new
services because of contractual obligations the registries entered into
that requires them to have new services evaluated to ensure those services
don't impact DNS security, stability or competition, something the
community required ICANN enforce as a result of the SiteFinder episode ages
ago. Registries can, of course, request that evaluation and I'm told some
have and are actually offering RDAP.But I would agree it is much easier to simply blame ICANN.
RDAP is totally different from other possible registry services since it's
already baked into registries contracts...
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm
specification 4. It's basically the same service already offered thru
WHOIS, RDDS, over a different protocol.
The contract already allows ICANN to trigger a requirement to support RDAP,
but doesn't allow registries to support if before they are required. ICANN
could have, and has been suggested to, allow it before it triggers the
requirement in order to have willing registries support it, and hasn't done
it.
So in this particular case I don't have any problems blaming ICANN... and
the great level of transparency of ICANN meetings being recorded and
transcribed provides plenty of evidence in that regard.
As for gTLD registries offering RDAP, I couldn't find any at
https://www.icann.org/resources/pages/rsep-2014-02-19-en, the page where
new registry services are described and published for comments... the only
registries I know deploying RDAP are ccTLDs, which do not operate inside
ICANN gTLD policy framework.
https://rdap.registro.br/domain/icannsaopaulo.br
https://rdap.nic.cz/domain/nic.cz
Rubens