The Whois roles are not well defined
Almost all of the discussion around whois has been based on implicit acceptance of the roles of registrant, admin contact and tech contact as if these had definite meaning. They don't. The person who actually controls the domain registration and the associated parameters, i.e. name servers, etc. is the person who has access to the account with the registrar. I don't know if there is widely agreed upon name of this role, so I'll call her the domain controller. If this group prefers a different name, I'll happily switch. It's the domain controller who populates the registrant, admin and tech fields. Most of the time, the names and contact information that is put into these fields is reasonably related to the common sense notion of what these terms mean, but unless I have missed something, there is nothing in either the rules or the operational practices that forces these to be meaningful. In the extreme, the controller can put in the names of people who have NO relationship with the domain. Viewed from this perspective, rather than decrying the high error rates, it might be more appropriate to be amazed at how well this system works. When the whois system was first created, the net -- and we're talking about the Arpanet, not the full blown Internet -- consisted of several dozen time-shared computers, each of which support several dozen users. The tech contact was what we'd now call the system administrator (sysadmin) and the admin contact was someone who had administrative authority over both the operations and the users. The list of contacts was intended to make it easy for the relevant people in authority to get in touch with each other when there was a problem. Those terms have been transliterated to the domain name system and scaled from hundreds to hundreds of millions. Nothing really survives being scaled up by a factor of a million without undergoing serious and substantial reworking. In my view, the extensive and overwrought discussion about who should have access to the contact information, how to validate the information, and how to reconcile all of this with privacy laws is troubled because there really isn't a firm foundation at to what this contact information means. The operational questions for contact information is fundamentally what obligation does the person designated in a particular role have when she's contacted, who should be allowed to contact the person, and under what circumstances. There is, of course, one particular role that is well defined. It's the billing contact. If the registrar sends a message to the billing contact and says the bill hasn't been paid, the billing contact either takes care of the problem or the registrar shuts down the account. There is also a reasonably well defined sequence related to domain name transfers. Is there more that is well defined? What are the implications of this line of reasoning? Well, for starters, what happens if we simply remove the admin and tech contacts? If there is an argument for continuing their existence, can we base it on operational authorities and responsibilities? Another, quite important but less obvious implication is to look at what information is NOT there that should be. The current ICANN contractual model is based on registries and registrars but pays no attention to name server operators. It's quite common for the registrar to operate the name servers for the registrant, but it is also quite common for the registrant to either operate her own name servers or to use a third party. There are companies that specialize in providing this service, and they are an important part of the ecosystem. Why does it matter that name server operators are not explicitly visible in the ICANN contractual model and registration data base? Because the name server operator sometimes needs to change the information in the registry that's associated with the domain name. There are two significant cases. One is when the name server operator changes the set of name servers associated with a domain name. This doesn't happen frequently, and when it does it usually affects a large fraction or all of the name server operator's customers. When that happens, the revised list of name servers has to be communicated to the registry and be published in the parent zone. Under the ICANN model, the only path for communicating with the registry is via the registrar, and the only path implemented by registrars is via the account holder, i.e. the person I called the controller. This means when a name server operator makes a change to its set of name servers, EACH of the name server operator's customers has to process an email message from the name server operator and make a manual change to the entry in her account. This is time-consuming, labor intensive and error prone. The other case is related to DNSSEC. The signatures associated with DNSSEC have expiration dates. If the name service is being provided by a name server operator, it will be the name server operator that will generate a new key and create a new DS record on a regular schedule and . This requires putting the new DS record in the parent. Again, since the only path is through the registrar... here are proposals for additional protocols to automate this process, but these have some complexity due to the need to work around the clumsiness of adhering to the limited business model. It ought to be possible for the domain controller to explicitly designate the name server operator and to authorize the name server operator to send changes to the name server records and/or the DS records whenever necessary. For those of you who have read this far and are wondering whether this really belongs in a discussion about RDS, the answer is yes, The RDS is a portion of the overall operation of the domain name system. It provides contact information for the essential functions of the system. In the ICANN system, the registrars are contracted parties and the name server operators are not, but that does not address the need for a more orderly operational relationship among these parties. More to come. Steve
Hi Steve A few inline comments ...
I don't know if there is widely agreed upon name of this role, so I'll call her the domain controller.
Account Holder is the term Registrars generally use (and that we've managed to train ICANN Compliance to understand)
It's the domain controller who populates the registrant, admin and tech fields
In some cases, but in a great number (like the millions of domains handled by resellers) no - it's whomever is ordering it, which can be many levels down from the actual account holder
In the extreme, the controller can put in the names of people who have NO relationship with the domain.
That happens (both inadvertently and deliberately) , and due to the IRTP_C "change of control" misinterpretation by ICANN staff, is now almost impossible to fix - for reasons unknown the rodent living in the enchanted castle appears reluctant to follow the change of control process which would remove him as the contact
The list of contacts was intended to make it easy for the relevant people in authority to get in touch with each other when there was a problem.
Indeed, although the days of going "oi, john, you made a typo on that A record, all your FTP connections are hitting my server, can you fix, and BTW 'Passw0rd' is probably not that secure! " ended last millennium, now your IDS just drops the entire ASN at the edge automatically, and any attempt to be helpful is usually followed by a UDRP, domain hijack attempt or ending up on a spam blacklist.
There is, of course, one particular role that is well defined. It's the billing contact. If the registrar sends a message to the billing contact and says the bill hasn't been paid, the billing contact either takes care of the problem or the registrar shuts down the account.
The billing contact on a domain has not had anything at all to do with who gets invoiced (or whatever) since the introduction of multiple registrars (so mid-90s)
what happens if we simply remove the admin and tech contacts?
If you lose the idea of that "role" having specific things they can "do" then those of us that like structures/heirarchies/standards/etc would lose another small piece of our souls' but t'interwebbyfacetweetnet would still work just fine :)
Because the name server operator sometimes needs to change the information in the registry that's associated with the domain name
Almost never (simply due to the disruption it can cause) would there be a mass changing of the nameservers needed on a domain - the cost of a record in a db or maintaining an old "brand name" domain for nameserver use is so minimal in comparison. They do need to update the "nameserver registration" data though (less disruptive but more frequently depending on their size/operations) - although the need to "register" nameservers in order to use them (as opposed to self-reference them) is simply a 30 year old design fault for gTLDs
it will be the name server operator that will generate a new key and create a new DS record on a regular schedule and . This requires putting the new DS record in the parent. Again, since the only path is through the registrar...
Another design flaw [ and a good reason not to use the "it-solves-no-known-problem" DNSSEC system ] As you said, ideas for solutions to that flaw (allowing a special category of contact/access/api-user) have been bounced around for years, but not really gained support (for security reasons more than anything) Rob --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 15 Feb 2018, at 19:05, Steve Crocker <steve@shinkuro.com> wrote:
Almost all of the discussion around whois has been based on implicit acceptance of the roles of registrant, admin contact and tech contact as if these had definite meaning. They don't.
The person who actually controls the domain registration and the associated parameters, i.e. name servers, etc. is the person who has access to the account with the registrar. I don't know if there is widely agreed upon name of this role, so I'll call her the domain controller. If this group prefers a different name, I'll happily switch.
It's the domain controller who populates the registrant, admin and tech fields. Most of the time, the names and contact information that is put into these fields is reasonably related to the common sense notion of what these terms mean, but unless I have missed something, there is nothing in either the rules or the operational practices that forces these to be meaningful. In the extreme, the controller can put in the names of people who have NO relationship with the domain. Viewed from this perspective, rather than decrying the high error rates, it might be more appropriate to be amazed at how well this system works.
When the whois system was first created, the net -- and we're talking about the Arpanet, not the full blown Internet -- consisted of several dozen time-shared computers, each of which support several dozen users. The tech contact was what we'd now call the system administrator (sysadmin) and the admin contact was someone who had administrative authority over both the operations and the users. The list of contacts was intended to make it easy for the relevant people in authority to get in touch with each other when there was a problem.
Those terms have been transliterated to the domain name system and scaled from hundreds to hundreds of millions. Nothing really survives being scaled up by a factor of a million without undergoing serious and substantial reworking.
In my view, the extensive and overwrought discussion about who should have access to the contact information, how to validate the information, and how to reconcile all of this with privacy laws is troubled because there really isn't a firm foundation at to what this contact information means. The operational questions for contact information is fundamentally what obligation does the person designated in a particular role have when she's contacted, who should be allowed to contact the person, and under what circumstances.
There is, of course, one particular role that is well defined. It's the billing contact. If the registrar sends a message to the billing contact and says the bill hasn't been paid, the billing contact either takes care of the problem or the registrar shuts down the account.
But why the registrar would send that contact to registry, or why it would appear on either party RDS ? Data minimisation suggests scrap billing contact altogether.
There is also a reasonably well defined sequence related to domain name transfers. Is there more that is well defined?
Currently the transfer regulations (IRTP) attribute meaning to the admin contact.
What are the implications of this line of reasoning? Well, for starters, what happens if we simply remove the admin and tech contacts? If there is an argument for continuing their existence, can we base it on operational authorities and responsibilities?
In the case of the admin contact, it could be an optional parameter where the account holder is not the domain portfolio administrator, but still exist. Or have the admin function split between copyright issue, intellectual property issues, information security issues etc.
Another, quite important but less obvious implication is to look at what information is NOT there that should be. The current ICANN contractual model is based on registries and registrars but pays no attention to name server operators. It's quite common for the registrar to operate the name servers for the registrant, but it is also quite common for the registrant to either operate her own name servers or to use a third party. There are companies that specialize in providing this service, and they are an important part of the ecosystem.
Why does it matter that name server operators are not explicitly visible in the ICANN contractual model and registration data base? Because the name server operator sometimes needs to change the information in the registry that's associated with the domain name. There are two significant cases. One is when the name server operator changes the set of name servers associated with a domain name. This doesn't happen frequently, and when it does it usually affects a large fraction or all of the name server operator's customers. When that happens, the revised list of name servers has to be communicated to the registry and be published in the parent zone.
Under the ICANN model, the only path for communicating with the registry is via the registrar, and the only path implemented by registrars is via the account holder, i.e. the person I called the controller. This means when a name server operator makes a change to its set of name servers, EACH of the name server operator's customers has to process an email message from the name server operator and make a manual change to the entry in her account. This is time-consuming, labor intensive and error prone.
The other case is related to DNSSEC. The signatures associated with DNSSEC have expiration dates. If the name service is being provided by a name server operator, it will be the name server operator that will generate a new key and create a new DS record on a regular schedule and . This requires putting the new DS record in the parent. Again, since the only path is through the registrar...
here are proposals for additional protocols to automate this process, but these have some complexity due to the need to work around the clumsiness of adhering to the limited business model. It ought to be possible for the domain controller to explicitly designate the name server operator and to authorize the name server operator to send changes to the name server records and/or the DS records whenever necessary.
For those of you who have read this far and are wondering whether this really belongs in a discussion about RDS, the answer is yes, The RDS is a portion of the overall operation of the domain name system. It provides contact information for the essential functions of the system. In the ICANN system, the registrars are contracted parties and the name server operators are not, but that does not address the need for a more orderly operational relationship among these parties.
Perhaps replacing the tech contact with an API key would achieve this goal ? And of course the API key would not be published in RDS, just its existence would be guaranteed by policy and it's up to the account holder to give the API key to someone running their DNS servers or not. But for RDS discussions, indeed the tech contact looks like something easier being removed. Rubens
Thanks Steve. I am glad to see that a few members have already responded and hope others will as well. I just want to share a concern about using the term ‘controller’. The term ‘data controller’ that is key for the GDPR could probably be easily confused with ‘domain controller’. That said the idea of coming up with a better term seems reasonable. Chuck From: gnso-rds-pdp-wg [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Steve Crocker Sent: Thursday, February 15, 2018 1:05 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] The Whois roles are not well defined Almost all of the discussion around whois has been based on implicit acceptance of the roles of registrant, admin contact and tech contact as if these had definite meaning. They don't. The person who actually controls the domain registration and the associated parameters, i.e. name servers, etc. is the person who has access to the account with the registrar. I don't know if there is widely agreed upon name of this role, so I'll call her the domain controller. If this group prefers a different name, I'll happily switch. It's the domain controller who populates the registrant, admin and tech fields. Most of the time, the names and contact information that is put into these fields is reasonably related to the common sense notion of what these terms mean, but unless I have missed something, there is nothing in either the rules or the operational practices that forces these to be meaningful. In the extreme, the controller can put in the names of people who have NO relationship with the domain. Viewed from this perspective, rather than decrying the high error rates, it might be more appropriate to be amazed at how well this system works. When the whois system was first created, the net -- and we're talking about the Arpanet, not the full blown Internet -- consisted of several dozen time-shared computers, each of which support several dozen users. The tech contact was what we'd now call the system administrator (sysadmin) and the admin contact was someone who had administrative authority over both the operations and the users. The list of contacts was intended to make it easy for the relevant people in authority to get in touch with each other when there was a problem. Those terms have been transliterated to the domain name system and scaled from hundreds to hundreds of millions. Nothing really survives being scaled up by a factor of a million without undergoing serious and substantial reworking. In my view, the extensive and overwrought discussion about who should have access to the contact information, how to validate the information, and how to reconcile all of this with privacy laws is troubled because there really isn't a firm foundation at to what this contact information means. The operational questions for contact information is fundamentally what obligation does the person designated in a particular role have when she's contacted, who should be allowed to contact the person, and under what circumstances. There is, of course, one particular role that is well defined. It's the billing contact. If the registrar sends a message to the billing contact and says the bill hasn't been paid, the billing contact either takes care of the problem or the registrar shuts down the account. There is also a reasonably well defined sequence related to domain name transfers. Is there more that is well defined? What are the implications of this line of reasoning? Well, for starters, what happens if we simply remove the admin and tech contacts? If there is an argument for continuing their existence, can we base it on operational authorities and responsibilities? Another, quite important but less obvious implication is to look at what information is NOT there that should be. The current ICANN contractual model is based on registries and registrars but pays no attention to name server operators. It's quite common for the registrar to operate the name servers for the registrant, but it is also quite common for the registrant to either operate her own name servers or to use a third party. There are companies that specialize in providing this service, and they are an important part of the ecosystem. Why does it matter that name server operators are not explicitly visible in the ICANN contractual model and registration data base? Because the name server operator sometimes needs to change the information in the registry that's associated with the domain name. There are two significant cases. One is when the name server operator changes the set of name servers associated with a domain name. This doesn't happen frequently, and when it does it usually affects a large fraction or all of the name server operator's customers. When that happens, the revised list of name servers has to be communicated to the registry and be published in the parent zone. Under the ICANN model, the only path for communicating with the registry is via the registrar, and the only path implemented by registrars is via the account holder, i.e. the person I called the controller. This means when a name server operator makes a change to its set of name servers, EACH of the name server operator's customers has to process an email message from the name server operator and make a manual change to the entry in her account. This is time-consuming, labor intensive and error prone. The other case is related to DNSSEC. The signatures associated with DNSSEC have expiration dates. If the name service is being provided by a name server operator, it will be the name server operator that will generate a new key and create a new DS record on a regular schedule and . This requires putting the new DS record in the parent. Again, since the only path is through the registrar... here are proposals for additional protocols to automate this process, but these have some complexity due to the need to work around the clumsiness of adhering to the limited business model. It ought to be possible for the domain controller to explicitly designate the name server operator and to authorize the name server operator to send changes to the name server records and/or the DS records whenever necessary. For those of you who have read this far and are wondering whether this really belongs in a discussion about RDS, the answer is yes, The RDS is a portion of the overall operation of the domain name system. It provides contact information for the essential functions of the system. In the ICANN system, the registrars are contracted parties and the name server operators are not, but that does not address the need for a more orderly operational relationship among these parties. More to come. Steve
Fair point. Rob Golding says "Account Holder" is the term commonly used. This seems fine to me -- descriptive, accurate and unprovocative. I'll use it in the future. Steve On Thu, Feb 15, 2018 at 8:15 PM, Chuck <consult@cgomes.com> wrote:
Thanks Steve. I am glad to see that a few members have already responded and hope others will as well.
I just want to share a concern about using the term ‘controller’. The term ‘data controller’ that is key for the GDPR could probably be easily confused with ‘domain controller’. That said the idea of coming up with a better term seems reasonable.
Chuck
*From:* gnso-rds-pdp-wg [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Steve Crocker *Sent:* Thursday, February 15, 2018 1:05 PM *To:* gnso-rds-pdp-wg@icann.org *Subject:* [gnso-rds-pdp-wg] The Whois roles are not well defined
Almost all of the discussion around whois has been based on implicit acceptance of the roles of registrant, admin contact and tech contact as if these had definite meaning. They don't.
The person who actually controls the domain registration and the associated parameters, i.e. name servers, etc. is the person who has access to the account with the registrar. I don't know if there is widely agreed upon name of this role, so I'll call her the domain controller. If this group prefers a different name, I'll happily switch.
It's the domain controller who populates the registrant, admin and tech fields. Most of the time, the names and contact information that is put into these fields is reasonably related to the common sense notion of what these terms mean, but unless I have missed something, there is nothing in either the rules or the operational practices that forces these to be meaningful. In the extreme, the controller can put in the names of people who have NO relationship with the domain. Viewed from this perspective, rather than decrying the high error rates, it might be more appropriate to be amazed at how well this system works.
When the whois system was first created, the net -- and we're talking about the Arpanet, not the full blown Internet -- consisted of several dozen time-shared computers, each of which support several dozen users. The tech contact was what we'd now call the system administrator (sysadmin) and the admin contact was someone who had administrative authority over both the operations and the users. The list of contacts was intended to make it easy for the relevant people in authority to get in touch with each other when there was a problem.
Those terms have been transliterated to the domain name system and scaled from hundreds to hundreds of millions. Nothing really survives being scaled up by a factor of a million without undergoing serious and substantial reworking.
In my view, the extensive and overwrought discussion about who should have access to the contact information, how to validate the information, and how to reconcile all of this with privacy laws is troubled because there really isn't a firm foundation at to what this contact information means. The operational questions for contact information is fundamentally what obligation does the person designated in a particular role have when she's contacted, who should be allowed to contact the person, and under what circumstances.
There is, of course, one particular role that is well defined. It's the billing contact. If the registrar sends a message to the billing contact and says the bill hasn't been paid, the billing contact either takes care of the problem or the registrar shuts down the account.
There is also a reasonably well defined sequence related to domain name transfers. Is there more that is well defined?
What are the implications of this line of reasoning? Well, for starters, what happens if we simply remove the admin and tech contacts? If there is an argument for continuing their existence, can we base it on operational authorities and responsibilities?
Another, quite important but less obvious implication is to look at what information is NOT there that should be. The current ICANN contractual model is based on registries and registrars but pays no attention to name server operators. It's quite common for the registrar to operate the name servers for the registrant, but it is also quite common for the registrant to either operate her own name servers or to use a third party. There are companies that specialize in providing this service, and they are an important part of the ecosystem.
Why does it matter that name server operators are not explicitly visible in the ICANN contractual model and registration data base? Because the name server operator sometimes needs to change the information in the registry that's associated with the domain name. There are two significant cases. One is when the name server operator changes the set of name servers associated with a domain name. This doesn't happen frequently, and when it does it usually affects a large fraction or all of the name server operator's customers. When that happens, the revised list of name servers has to be communicated to the registry and be published in the parent zone.
Under the ICANN model, the only path for communicating with the registry is via the registrar, and the only path implemented by registrars is via the account holder, i.e. the person I called the controller. This means when a name server operator makes a change to its set of name servers, EACH of the name server operator's customers has to process an email message from the name server operator and make a manual change to the entry in her account. This is time-consuming, labor intensive and error prone.
The other case is related to DNSSEC. The signatures associated with DNSSEC have expiration dates. If the name service is being provided by a name server operator, it will be the name server operator that will generate a new key and create a new DS record on a regular schedule and . This requires putting the new DS record in the parent. Again, since the only path is through the registrar...
here are proposals for additional protocols to automate this process, but these have some complexity due to the need to work around the clumsiness of adhering to the limited business model. It ought to be possible for the domain controller to explicitly designate the name server operator and to authorize the name server operator to send changes to the name server records and/or the DS records whenever necessary.
For those of you who have read this far and are wondering whether this really belongs in a discussion about RDS, the answer is yes, The RDS is a portion of the overall operation of the domain name system. It provides contact information for the essential functions of the system. In the ICANN system, the registrars are contracted parties and the name server operators are not, but that does not address the need for a more orderly operational relationship among these parties.
More to come.
Steve
Steve You raise some interesting points. In another forum there was discussion around some of the current roles used in whois and how they change. The data from several very large registrars showed that more than 95% of domains have the same contact for all roles. I’d fundamentally disagree with your comment about the billing contact in whois. For most registrars (as noted above) it’s just a field that gets populated and isn’t used for anything. If we want to reach the person who pays us we use what we have in our billing systems, which could easily be something completely different. As for DNS operators – giving them an expanded role as you are suggesting (and not for the first time) has much wider implications than whois. While it might be something that is worth exploring I’m not sure that here is the best place to do it, as it opens up a rather large can of worms in relation to contractual relationships etc., Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ http://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
Agreed on all points made by Michele. Thanks, Theo Geurts On 16-2-2018 13:14, Michele Neylon - Blacknight wrote:
Steve
You raise some interesting points.
In another forum there was discussion around some of the current roles used in whois and how they change. The data from several very large registrars showed that more than 95% of domains have the same contact for all roles.
I’d fundamentally disagree with your comment about the billing contact in whois. For most registrars (as noted above) it’s just a field that gets populated and isn’t used for anything.
If we want to reach the person who pays us we use what we have in our billing systems, which could easily be something completely different.
As for DNS operators – giving them an expanded role as you are suggesting (and not for the first time) has much wider implications than whois. While it might be something that is worth exploring I’m not sure that here is the best place to do it, as it opens up a rather large can of worms in relation to contractual relationships etc.,
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Steve, interesting indeed. As registrar, we only need the registrant contact, and potentially the admin contact, if the registrant choses to employ a third party for their domain management. Billing and tech contacts are irrelevant to most of us, we rather look at the account details of our customer for billing, as Michele points out. From my experience, most registrants use the same details for all contacts anyhow, just to fill them. As for what goes into these contacts, for our business purposes, we actually only need Registrant name and Organization (if applicable), as well as their email address. In some rare cases, we may need the phone number and even rarer cases the postal address for verification purposes, but for 99.99% of registrations, these are newer used by registrars for the provision of the service itself. Of course some registrars use these data points for other purposes such as upselling, but I'd consider that an ancillary use. Best, Volker Am 16.02.2018 um 13:14 schrieb Michele Neylon - Blacknight:
Steve
You raise some interesting points.
In another forum there was discussion around some of the current roles used in whois and how they change. The data from several very large registrars showed that more than 95% of domains have the same contact for all roles.
I’d fundamentally disagree with your comment about the billing contact in whois. For most registrars (as noted above) it’s just a field that gets populated and isn’t used for anything.
If we want to reach the person who pays us we use what we have in our billing systems, which could easily be something completely different.
As for DNS operators – giving them an expanded role as you are suggesting (and not for the first time) has much wider implications than whois. While it might be something that is worth exploring I’m not sure that here is the best place to do it, as it opens up a rather large can of worms in relation to contractual relationships etc.,
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Hi Volker, Honest question here, related to this line at the end of your email below: "Of course some registrars use these data points for other purposes such as upselling, but I'd consider that an ancillary use." I'm interpreting this to mean some registrars may be using data collected for the purpose of meeting the Whois obligation, for "upselling" other services to the registrant later on. Maybe mailing them an advert for hosting services or something. If that is an incorrect interpretation then the question below is probably off target. Would it be accurate to state that using the Whois data, collected for the purpose of the domain registration, for upselling other services (even though done by the registrar itself) is possibly a violation of GDPR? Tim On Fri, Feb 16, 2018 at 5:41 AM, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Steve,
interesting indeed. As registrar, we only need the registrant contact, and potentially the admin contact, if the registrant choses to employ a third party for their domain management. Billing and tech contacts are irrelevant to most of us, we rather look at the account details of our customer for billing, as Michele points out.
From my experience, most registrants use the same details for all contacts anyhow, just to fill them.
As for what goes into these contacts, for our business purposes, we actually only need Registrant name and Organization (if applicable), as well as their email address. In some rare cases, we may need the phone number and even rarer cases the postal address for verification purposes, but for 99.99% of registrations, these are newer used by registrars for the provision of the service itself. Of course some registrars use these data points for other purposes such as upselling, but I'd consider that an ancillary use.
Best,
Volker
Am 16.02.2018 um 13:14 schrieb Michele Neylon - Blacknight:
Steve
You raise some interesting points.
In another forum there was discussion around some of the current roles used in whois and how they change. The data from several very large registrars showed that more than 95% of domains have the same contact for all roles.
I’d fundamentally disagree with your comment about the billing contact in whois. For most registrars (as noted above) it’s just a field that gets populated and isn’t used for anything.
If we want to reach the person who pays us we use what we have in our billing systems, which could easily be something completely different.
As for DNS operators – giving them an expanded role as you are suggesting (and not for the first time) has much wider implications than whois. While it might be something that is worth exploring I’m not sure that here is the best place to do it, as it opens up a rather large can of worms in relation to contractual relationships etc.,
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072 <+353%2059%20918%203072>
Direct Dial: +353 (0)59 9183090 <+353%2059%20918%203090>
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Depends on the agreement. It can be legitimate use of the data, if it is framed properly. For clarity, we do not market to our registrants, we market to our customers and we declare in advance we will do so. Best, Volker
On 17. Feb 2018, at 01:16, Chen, Tim <tim@domaintools.com> wrote:
Hi Volker,
Honest question here, related to this line at the end of your email below:
"Of course some registrars use these data points for other purposes such as upselling, but I'd consider that an ancillary use."
I'm interpreting this to mean some registrars may be using data collected for the purpose of meeting the Whois obligation, for "upselling" other services to the registrant later on. Maybe mailing them an advert for hosting services or something. If that is an incorrect interpretation then the question below is probably off target.
Would it be accurate to state that using the Whois data, collected for the purpose of the domain registration, for upselling other services (even though done by the registrar itself) is possibly a violation of GDPR?
Tim
On Fri, Feb 16, 2018 at 5:41 AM, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote: Hi Steve, interesting indeed. As registrar, we only need the registrant contact, and potentially the admin contact, if the registrant choses to employ a third party for their domain management. Billing and tech contacts are irrelevant to most of us, we rather look at the account details of our customer for billing, as Michele points out.
From my experience, most registrants use the same details for all contacts anyhow, just to fill them. As for what goes into these contacts, for our business purposes, we actually only need Registrant name and Organization (if applicable), as well as their email address. In some rare cases, we may need the phone number and even rarer cases the postal address for verification purposes, but for 99.99% of registrations, these are newer used by registrars for the provision of the service itself. Of course some registrars use these data points for other purposes such as upselling, but I'd consider that an ancillary use. Best,
Volker
Am 16.02.2018 um 13:14 schrieb Michele Neylon - Blacknight:
Steve
You raise some interesting points.
In another forum there was discussion around some of the current roles used in whois and how they change. The data from several very large registrars showed that more than 95% of domains have the same contact for all roles.
I’d fundamentally disagree with your comment about the billing contact in whois. For most registrars (as noted above) it’s just a field that gets populated and isn’t used for anything.
If we want to reach the person who pays us we use what we have in our billing systems, which could easily be something completely different.
As for DNS operators – giving them an expanded role as you are suggesting (and not for the first time) has much wider implications than whois. While it might be something that is worth exploring I’m not sure that here is the best place to do it, as it opens up a rather large can of worms in relation to contractual relationships etc.,
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/ <https://www.blacknight.com/> http://blacknight.blog/ <http://blacknight.blog/> Intl. +353 (0) 59 9183072 <tel:+353%2059%20918%203072> Direct Dial: +353 (0)59 9183090 <tel:+353%2059%20918%203090> Personal blog: https://michele.blog/ <https://michele.blog/> Some thoughts: https://ceo.hosting/ <https://ceo.hosting/> -------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 <>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg> -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Michele, Thanks. I take your point about the billing contact. It too is supplied by the account holder and may or may not have anything to do with the person actually responsible for and capable of paying the bills. Re the role of the name server operator, what other forum would you suggest? It's a long overdue discussion. Moreover, since the reason it's important is related to access to and modification of the account holder's records, I think it really is within the scope of this discussion. The changes needed to accommodate the proper set of interactions between the name server operator and the registrar/registry are closely related to the interactions between the account holder and the registrar. Further, it will require identifying the name server operator in some fashion and hence raise the same set of issues re privacy as we're talking about for the other roles. Steve On Fri, Feb 16, 2018 at 7:14 AM, Michele Neylon - Blacknight < michele@blacknight.com> wrote:
Steve
You raise some interesting points.
In another forum there was discussion around some of the current roles used in whois and how they change. The data from several very large registrars showed that more than 95% of domains have the same contact for all roles.
I’d fundamentally disagree with your comment about the billing contact in whois. For most registrars (as noted above) it’s just a field that gets populated and isn’t used for anything.
If we want to reach the person who pays us we use what we have in our billing systems, which could easily be something completely different.
As for DNS operators – giving them an expanded role as you are suggesting (and not for the first time) has much wider implications than whois. While it might be something that is worth exploring I’m not sure that here is the best place to do it, as it opens up a rather large can of worms in relation to contractual relationships etc.,
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072 <+353%2059%20918%203072>
Direct Dial: +353 (0)59 9183090 <+353%2059%20918%203090>
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
participants (8)
-
Chen, Tim -
Chuck -
Michele Neylon - Blacknight -
Rob Golding -
Rubens Kuhl -
Steve Crocker -
Theo Geurts -
Volker Greimann