key concepts: say "contact data" when that is what we mean
Speaking of key concepts... people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data ... is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: * Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) * Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. * Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts... people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data ... is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: ******** Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) ******** Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. ******** Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
Although this came in at a next level of detail, the EWG principles divided data into at least three categories: Data collected from registries and registrars Data collected from registrants Data collected from contacts themselves As well as data collected by registries/registrars not shared with the RDS. I think deliberation may show that the taxonomy of data collected and sometimes disclosed about registered domain names really stems from other key concepts such as who data is collected from and for what purposes. Sent from Lisa Phifer's iPhone
On Dec 7, 2016, at 8:20 AM, Gomes, Chuck <cgomes@verisign.com> wrote:
Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice.
Chuck
From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean
Speaking of key concepts… people often say “registration data” when they really mean “contact data.” Being plain and specific here can help discussion in our group. The concept will come up in next week’s discussion.
There are basically two kinds of “registration data”. The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain’s status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial.
The second kind of registration data is CONTACT DATA – contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it’s ultimately supplied by the registrants. When people talk about “registration data accuracy” and “registration data validation” they are really talking about the accuracy of CONTACT DATA, not all “registration data.”
In the coming discussions, one approach could be: There are good reasons to publish the thin data … is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It’s an attempt to disentangle concepts and find a way forward. Not all data is the same, so let’s stop treating all data the same. We may not have to iterate repeatedly about thin data.
Even the EWG’s language wasn’t always clear and specific in this area. Here’s the question we will begin with next week:
Should gTLD registration data be accessible for any purpose or only for specific purposes? “The EWG unanimously recommends abandoning today’s WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use.”
What the EWG really meant was: · Give public, anonymous access to the THIN data. (“Basic data” as the EWG called it.) · Don’t give every user the same anonymous public access to (“often inaccurate”) gTLD CONTACT DATA. · Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only.
All best, --Greg
********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On Wed, Dec 07, 2016 at 08:32:39AM -0700, Lisa Phifer wrote:
Although this came in at a next level of detail, the EWG principles divided data into at least three categories:
While those categories are useful for evaluating the source of the data, they're not helpful in evaluating whether a given piece of data has operational consequences for the Internet. This comes down to a question that I think Jim Galvin keeps asking, which is why we want the RDS in the first place. I think at least one minimal goal, if we want one at all, is to support operation of the Internet in respect of domain name resolution. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
ICANN is finalizing its new "Registry Registration Data Directory Services Consistent Labeling and Display Policy", or CLDP. This standardizes what fields exist in gTLD WHOIS output, with consistent names. It's quite clear what is contact data and what is not. The new CLDP requirements are here: https://www.icann.org/en/system/files/files/proposed-revised-registry-rdds-c... Yes, some registries have non-standard data fields that they publish in WHOIS. These are exceptions and corner cases but these don't present much to get hung up on. Examples are: * trademark data (which is not contact data or PII) * community IDs (like in .AERO) that identify whether a registrant is a member of the TLD's community. Pretty easy to tell whether these reveal individuals' data or not. --Greg From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: Wednesday, December 7, 2016 10:20 AM To: Greg Aaron <gca@icginc.com>; gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts... people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data ... is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: * Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) * Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. * Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
Greg, Would it make sense to divide data into three categories: 1) thin data; 2) contact data; and 3) other data. You may be right that the 'other data' category may not be anything to get hung up on but we may need to consider it; hopefully it would be easy to deal with. Chuck From: Greg Aaron [mailto:gca@icginc.com] Sent: Wednesday, December 07, 2016 2:57 PM To: Gomes, Chuck <cgomes@verisign.com>; gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean ICANN is finalizing its new "Registry Registration Data Directory Services Consistent Labeling and Display Policy", or CLDP. This standardizes what fields exist in gTLD WHOIS output, with consistent names. It's quite clear what is contact data and what is not. The new CLDP requirements are here: https://www.icann.org/en/system/files/files/proposed-revised-registry-rdds-c... Yes, some registries have non-standard data fields that they publish in WHOIS. These are exceptions and corner cases but these don't present much to get hung up on. Examples are: ******** trademark data (which is not contact data or PII) ******** community IDs (like in .AERO) that identify whether a registrant is a member of the TLD's community. Pretty easy to tell whether these reveal individuals' data or not. --Greg From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: Wednesday, December 7, 2016 10:20 AM To: Greg Aaron <gca@icginc.com<mailto:gca@icginc.com>>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts... people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data ... is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: ******** Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) ******** Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. ******** Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
OK. From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: Wednesday, December 7, 2016 3:45 PM To: Greg Aaron <gca@icginc.com>; gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Greg, Would it make sense to divide data into three categories: 1) thin data; 2) contact data; and 3) other data. You may be right that the 'other data' category may not be anything to get hung up on but we may need to consider it; hopefully it would be easy to deal with. Chuck From: Greg Aaron [mailto:gca@icginc.com] Sent: Wednesday, December 07, 2016 2:57 PM To: Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean ICANN is finalizing its new "Registry Registration Data Directory Services Consistent Labeling and Display Policy", or CLDP. This standardizes what fields exist in gTLD WHOIS output, with consistent names. It's quite clear what is contact data and what is not. The new CLDP requirements are here: https://www.icann.org/en/system/files/files/proposed-revised-registry-rdds-c... Yes, some registries have non-standard data fields that they publish in WHOIS. These are exceptions and corner cases but these don't present much to get hung up on. Examples are: * trademark data (which is not contact data or PII) * community IDs (like in .AERO) that identify whether a registrant is a member of the TLD's community. Pretty easy to tell whether these reveal individuals' data or not. --Greg From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: Wednesday, December 7, 2016 10:20 AM To: Greg Aaron <gca@icginc.com<mailto:gca@icginc.com>>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts... people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data ... is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: * Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) * Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. * Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
On Wed, Dec 07, 2016 at 07:56:50PM +0000, Greg Aaron wrote:
Yes, some registries have non-standard data fields that they publish in WHOIS.
Pretty easy to tell whether these reveal individuals' data or not.
Clearly, though, we might want to make a recommendation about cases that are obviously PII. I think it'd be easier to start with the common cases of the "thin" data just because that stuff is common. As we get experience with dealing with tricky fields, we might tackle some of the more corner cases or build up some stories about how to handle generic cases. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Seems like a reasonable suggestion to me Andrew. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Wednesday, December 07, 2016 4:11 PM To: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean On Wed, Dec 07, 2016 at 07:56:50PM +0000, Greg Aaron wrote:
Yes, some registries have non-standard data fields that they publish in WHOIS.
Pretty easy to tell whether these reveal individuals' data or not.
Clearly, though, we might want to make a recommendation about cases that are obviously PII. I think it'd be easier to start with the common cases of the "thin" data just because that stuff is common. As we get experience with dealing with tricky fields, we might tackle some of the more corner cases or build up some stories about how to handle generic cases. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Chuck, I appreciate Greg's historical context of Whois data primarily being for purposes of "contacting" the registrant of a domain name using those data fields with personally identifying information. However, I think introducing/relying upon the concept of "CONTACT DATA" as proposed by Greg while well intentioned will only lead to greater confusion. First Greg acknowledges that not ALL data other than the thin technical data falls within his CONTACT DATA definition (trademark, nexus, reseller, etc). So we begin today with a model that is less than 100% inclusive and will likely become less inclusive as more innovative uses of the RDS and Whois data are created. Second, the use of this terminology ignores the reality in the marketplace that Registrant data is widely relied upon to make legal determinations (i.e. ownership, authority to transfer a domain name, infringement, etc.). When law enforcement is trying to shut down a counterfeit operation, they are not looking to use this data to 'contact" the registrant, but instead 'arrest" him/her. I understand how the term "contact data" provides a certain comfort level to Stephanie and the valid concerns she has. However, as someone that is involved in making legal determinations regarding the ownership rights (property/service contract) concerning domain name registrations on a regular basis, this concept of "Contact Data" will just lead to a lot of confusion. The whole legal construct (private contractual rights) upon which the domain name system is based recognizes the Registrant and the Registrant Data that it provides. In fact ICANN's Whois web page makes the following statement: "ICANN's WHOIS Lookup gives you the ability to lookup any generic domains, such as "icann.org" to find out the registered domain owner." (emphasis added) Again this data by ICANN's own admission is relied upon to make "ownership" decisions NOT mere "contact" information. So I think we stick to one of the first things I learned as a young engineer. Keep It Simple Stupid (KISS) Thin Data - the minimum technical data necessary for a registry to perform its function as a registry operator in a shared registry system. Thick Data - All data associated with a domain name registration made available via Whois/RDS, which may include Personal Identifying Information (PII) Again I appreciate the constructive efforts of Greg, Stephanie and others, but I just do not see this concept scaling meaningfully. Best regards, Michael From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: Wednesday, December 7, 2016 10:20 AM To: gca@icginc.com; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts. people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data . is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: * Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) * Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. * Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
Thanks Mike. I am glad to see this discussion going on in advance of considering the first users/purposes question: "Should gTLD registration data be accessible for any purpose or only for specific purposes?" Chuck From: Michael D. Palage [mailto:michael@palage.com] Sent: Wednesday, December 07, 2016 4:13 PM To: Gomes, Chuck <cgomes@verisign.com>; gca@icginc.com; gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Chuck, I appreciate Greg's historical context of Whois data primarily being for purposes of "contacting" the registrant of a domain name using those data fields with personally identifying information. However, I think introducing/relying upon the concept of "CONTACT DATA" as proposed by Greg while well intentioned will only lead to greater confusion. First Greg acknowledges that not ALL data other than the thin technical data falls within his CONTACT DATA definition (trademark, nexus, reseller, etc). So we begin today with a model that is less than 100% inclusive and will likely become less inclusive as more innovative uses of the RDS and Whois data are created. Second, the use of this terminology ignores the reality in the marketplace that Registrant data is widely relied upon to make legal determinations (i.e. ownership, authority to transfer a domain name, infringement, etc.). When law enforcement is trying to shut down a counterfeit operation, they are not looking to use this data to 'contact" the registrant, but instead 'arrest" him/her. I understand how the term "contact data" provides a certain comfort level to Stephanie and the valid concerns she has. However, as someone that is involved in making legal determinations regarding the ownership rights (property/service contract) concerning domain name registrations on a regular basis, this concept of "Contact Data" will just lead to a lot of confusion. The whole legal construct (private contractual rights) upon which the domain name system is based recognizes the Registrant and the Registrant Data that it provides. In fact ICANN's Whois web page makes the following statement: "ICANN's WHOIS Lookup gives you the ability to lookup any generic domains, such as "icann.org" to find out the registered domain owner." (emphasis added) Again this data by ICANN's own admission is relied upon to make "ownership" decisions NOT mere "contact" information. So I think we stick to one of the first things I learned as a young engineer. Keep It Simple Stupid (KISS) Thin Data - the minimum technical data necessary for a registry to perform its function as a registry operator in a shared registry system. Thick Data - All data associated with a domain name registration made available via Whois/RDS, which may include Personal Identifying Information (PII) Again I appreciate the constructive efforts of Greg, Stephanie and others, but I just do not see this concept scaling meaningfully. Best regards, Michael From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: Wednesday, December 7, 2016 10:20 AM To: gca@icginc.com<mailto:gca@icginc.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts... people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data ... is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: ******** Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) ******** Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. ******** Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
Chuck, This is where a choice/orientation of words may have significant legal distinction. (My text) - All data associated with a domain name registration (WG Text) - Registration Data I am taking a much more expansive view of data associated with a domain name registration to include data potentially NOT originally provided by a registrant at the time of registration. Versus the potentially more restrictive definition of only data provided by Registrant to Registrar at the time of registration. Take for example a .BRAND registry where licensees of that trademark owner are permitted to register in that .BRAND TLD. As part of promoting awareness to consumers, the registry operator (trademark owner) may desire to include/append authoritative data associated with each licensees consumer ranking (e.g. rating 1 thru 5 stars) so that consumers can better choose which licensee to conduct business. Because this ranking may change over time, the Registrant/Licensee is NOT in a position to provide this data as it appears in the RDS/WHOIS output. Only the Registry Operator (trademark owner) would be best positioned to include this authoritative data in the RDS/Whois output. The point I am trying to make is that innovation has only just begun in connection with the new gTLD expansion. While I respect the rights of privacy advocates to safeguard registrant PII, I do not want broad policy statements to have unintended consequences in impeding future innovation. Best regards, Michael From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: Wednesday, December 7, 2016 4:34 PM To: michael@palage.com; gca@icginc.com; gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Mike. I am glad to see this discussion going on in advance of considering the first users/purposes question: "Should gTLD registration data be accessible for any purpose or only for specific purposes?" Chuck From: Michael D. Palage [mailto:michael@palage.com] Sent: Wednesday, December 07, 2016 4:13 PM To: Gomes, Chuck <cgomes@verisign.com <mailto:cgomes@verisign.com> >; gca@icginc.com <mailto:gca@icginc.com> ; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Chuck, I appreciate Greg's historical context of Whois data primarily being for purposes of "contacting" the registrant of a domain name using those data fields with personally identifying information. However, I think introducing/relying upon the concept of "CONTACT DATA" as proposed by Greg while well intentioned will only lead to greater confusion. First Greg acknowledges that not ALL data other than the thin technical data falls within his CONTACT DATA definition (trademark, nexus, reseller, etc). So we begin today with a model that is less than 100% inclusive and will likely become less inclusive as more innovative uses of the RDS and Whois data are created. Second, the use of this terminology ignores the reality in the marketplace that Registrant data is widely relied upon to make legal determinations (i.e. ownership, authority to transfer a domain name, infringement, etc.). When law enforcement is trying to shut down a counterfeit operation, they are not looking to use this data to 'contact" the registrant, but instead 'arrest" him/her. I understand how the term "contact data" provides a certain comfort level to Stephanie and the valid concerns she has. However, as someone that is involved in making legal determinations regarding the ownership rights (property/service contract) concerning domain name registrations on a regular basis, this concept of "Contact Data" will just lead to a lot of confusion. The whole legal construct (private contractual rights) upon which the domain name system is based recognizes the Registrant and the Registrant Data that it provides. In fact ICANN's Whois web page makes the following statement: "ICANN's WHOIS Lookup gives you the ability to lookup any generic domains, such as "icann.org" to find out the registered domain owner." (emphasis added) Again this data by ICANN's own admission is relied upon to make "ownership" decisions NOT mere "contact" information. So I think we stick to one of the first things I learned as a young engineer. Keep It Simple Stupid (KISS) Thin Data - the minimum technical data necessary for a registry to perform its function as a registry operator in a shared registry system. Thick Data - All data associated with a domain name registration made available via Whois/RDS, which may include Personal Identifying Information (PII) Again I appreciate the constructive efforts of Greg, Stephanie and others, but I just do not see this concept scaling meaningfully. Best regards, Michael From: gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: Wednesday, December 7, 2016 10:20 AM To: gca@icginc.com <mailto:gca@icginc.com> ; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts. people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data . is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: * Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) * Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. * Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
Understand Mike. This illustrates why we need as broad a representation in the WG as possible. Chuck From: Michael D. Palage [mailto:michael@palage.com] Sent: Wednesday, December 07, 2016 5:04 PM To: Gomes, Chuck <cgomes@verisign.com>; gca@icginc.com; gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Chuck, This is where a choice/orientation of words may have significant legal distinction. (My text) - All data associated with a domain name registration (WG Text) - Registration Data I am taking a much more expansive view of data associated with a domain name registration to include data potentially NOT originally provided by a registrant at the time of registration. Versus the potentially more restrictive definition of only data provided by Registrant to Registrar at the time of registration. Take for example a .BRAND registry where licensees of that trademark owner are permitted to register in that .BRAND TLD. As part of promoting awareness to consumers, the registry operator (trademark owner) may desire to include/append authoritative data associated with each licensees consumer ranking (e.g. rating 1 thru 5 stars) so that consumers can better choose which licensee to conduct business. Because this ranking may change over time, the Registrant/Licensee is NOT in a position to provide this data as it appears in the RDS/WHOIS output. Only the Registry Operator (trademark owner) would be best positioned to include this authoritative data in the RDS/Whois output. The point I am trying to make is that innovation has only just begun in connection with the new gTLD expansion. While I respect the rights of privacy advocates to safeguard registrant PII, I do not want broad policy statements to have unintended consequences in impeding future innovation. Best regards, Michael From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: Wednesday, December 7, 2016 4:34 PM To: michael@palage.com<mailto:michael@palage.com>; gca@icginc.com<mailto:gca@icginc.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Mike. I am glad to see this discussion going on in advance of considering the first users/purposes question: "Should gTLD registration data be accessible for any purpose or only for specific purposes?" Chuck From: Michael D. Palage [mailto:michael@palage.com] Sent: Wednesday, December 07, 2016 4:13 PM To: Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>>; gca@icginc.com<mailto:gca@icginc.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Chuck, I appreciate Greg's historical context of Whois data primarily being for purposes of "contacting" the registrant of a domain name using those data fields with personally identifying information. However, I think introducing/relying upon the concept of "CONTACT DATA" as proposed by Greg while well intentioned will only lead to greater confusion. First Greg acknowledges that not ALL data other than the thin technical data falls within his CONTACT DATA definition (trademark, nexus, reseller, etc). So we begin today with a model that is less than 100% inclusive and will likely become less inclusive as more innovative uses of the RDS and Whois data are created. Second, the use of this terminology ignores the reality in the marketplace that Registrant data is widely relied upon to make legal determinations (i.e. ownership, authority to transfer a domain name, infringement, etc.). When law enforcement is trying to shut down a counterfeit operation, they are not looking to use this data to 'contact" the registrant, but instead 'arrest" him/her. I understand how the term "contact data" provides a certain comfort level to Stephanie and the valid concerns she has. However, as someone that is involved in making legal determinations regarding the ownership rights (property/service contract) concerning domain name registrations on a regular basis, this concept of "Contact Data" will just lead to a lot of confusion. The whole legal construct (private contractual rights) upon which the domain name system is based recognizes the Registrant and the Registrant Data that it provides. In fact ICANN's Whois web page makes the following statement: "ICANN's WHOIS Lookup gives you the ability to lookup any generic domains, such as "icann.org" to find out the registered domain owner." (emphasis added) Again this data by ICANN's own admission is relied upon to make "ownership" decisions NOT mere "contact" information. So I think we stick to one of the first things I learned as a young engineer. Keep It Simple Stupid (KISS) Thin Data - the minimum technical data necessary for a registry to perform its function as a registry operator in a shared registry system. Thick Data - All data associated with a domain name registration made available via Whois/RDS, which may include Personal Identifying Information (PII) Again I appreciate the constructive efforts of Greg, Stephanie and others, but I just do not see this concept scaling meaningfully. Best regards, Michael From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: Wednesday, December 7, 2016 10:20 AM To: gca@icginc.com<mailto:gca@icginc.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts... people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data ... is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: ******** Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) ******** Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. ******** Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
BTW, much of the thin data in WHOIS is not even "collected" from or provided by the registrant. Much of it is generated automatically at the registry, as a key registry function/responsibility. When you register a domain: * the registry knows what registrar is creating the domain, and records that and associates the registrar's IANA ID. The registry then displays those in WHOIS. * policy dictates what initial domain statuses there are. * the registrar indicates how many years the registrant wants, but the create/updated/expiration timestamps are generated and maintained by the registry. * Nameserver data is provided by the registrant. (Unless he or she didn't specify any, in which case the registrar often provides defaults.) * Domain statuses can be manipulated after the domain's out of AGP. Depending on the status type and the situation, they can be added and deleted by the registrant, the registrar, and/or by the registry. None of these thin data fields are sensitive info AFAIK. All best, --Greg From: Michael D. Palage [mailto:michael@palage.com] Sent: Wednesday, December 7, 2016 5:04 PM To: 'Gomes, Chuck' <cgomes@verisign.com>; Greg Aaron <gca@icginc.com>; gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Chuck, This is where a choice/orientation of words may have significant legal distinction. (My text) - All data associated with a domain name registration (WG Text) - Registration Data I am taking a much more expansive view of data associated with a domain name registration to include data potentially NOT originally provided by a registrant at the time of registration. Versus the potentially more restrictive definition of only data provided by Registrant to Registrar at the time of registration. Take for example a .BRAND registry where licensees of that trademark owner are permitted to register in that .BRAND TLD. As part of promoting awareness to consumers, the registry operator (trademark owner) may desire to include/append authoritative data associated with each licensees consumer ranking (e.g. rating 1 thru 5 stars) so that consumers can better choose which licensee to conduct business. Because this ranking may change over time, the Registrant/Licensee is NOT in a position to provide this data as it appears in the RDS/WHOIS output. Only the Registry Operator (trademark owner) would be best positioned to include this authoritative data in the RDS/Whois output. The point I am trying to make is that innovation has only just begun in connection with the new gTLD expansion. While I respect the rights of privacy advocates to safeguard registrant PII, I do not want broad policy statements to have unintended consequences in impeding future innovation. Best regards, Michael From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: Wednesday, December 7, 2016 4:34 PM To: michael@palage.com<mailto:michael@palage.com>; gca@icginc.com<mailto:gca@icginc.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Mike. I am glad to see this discussion going on in advance of considering the first users/purposes question: "Should gTLD registration data be accessible for any purpose or only for specific purposes?" Chuck From: Michael D. Palage [mailto:michael@palage.com] Sent: Wednesday, December 07, 2016 4:13 PM To: Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>>; gca@icginc.com<mailto:gca@icginc.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] RE: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Chuck, I appreciate Greg's historical context of Whois data primarily being for purposes of "contacting" the registrant of a domain name using those data fields with personally identifying information. However, I think introducing/relying upon the concept of "CONTACT DATA" as proposed by Greg while well intentioned will only lead to greater confusion. First Greg acknowledges that not ALL data other than the thin technical data falls within his CONTACT DATA definition (trademark, nexus, reseller, etc). So we begin today with a model that is less than 100% inclusive and will likely become less inclusive as more innovative uses of the RDS and Whois data are created. Second, the use of this terminology ignores the reality in the marketplace that Registrant data is widely relied upon to make legal determinations (i.e. ownership, authority to transfer a domain name, infringement, etc.). When law enforcement is trying to shut down a counterfeit operation, they are not looking to use this data to 'contact" the registrant, but instead 'arrest" him/her. I understand how the term "contact data" provides a certain comfort level to Stephanie and the valid concerns she has. However, as someone that is involved in making legal determinations regarding the ownership rights (property/service contract) concerning domain name registrations on a regular basis, this concept of "Contact Data" will just lead to a lot of confusion. The whole legal construct (private contractual rights) upon which the domain name system is based recognizes the Registrant and the Registrant Data that it provides. In fact ICANN's Whois web page makes the following statement: "ICANN's WHOIS Lookup gives you the ability to lookup any generic domains, such as "icann.org" to find out the registered domain owner." (emphasis added) Again this data by ICANN's own admission is relied upon to make "ownership" decisions NOT mere "contact" information. So I think we stick to one of the first things I learned as a young engineer. Keep It Simple Stupid (KISS) Thin Data - the minimum technical data necessary for a registry to perform its function as a registry operator in a shared registry system. Thick Data - All data associated with a domain name registration made available via Whois/RDS, which may include Personal Identifying Information (PII) Again I appreciate the constructive efforts of Greg, Stephanie and others, but I just do not see this concept scaling meaningfully. Best regards, Michael From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: Wednesday, December 7, 2016 10:20 AM To: gca@icginc.com<mailto:gca@icginc.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Thanks Greg for the helpful suggestion. I have one question for you and others: If we exclude THIN DATA, is there any data we will need to consider that could not be accurately classified as CONTACT DATA. If not, then dividing data into these two categories should suffice. Chuck From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 9:55 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Speaking of key concepts... people often say "registration data" when they really mean "contact data." Being plain and specific here can help discussion in our group. The concept will come up in next week's discussion. There are basically two kinds of "registration data". The first is called the THIN DATA. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain's status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial. The second kind of registration data is CONTACT DATA - contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it's ultimately supplied by the registrants. When people talk about "registration data accuracy" and "registration data validation" they are really talking about the accuracy of CONTACT DATA, not all "registration data." In the coming discussions, one approach could be: There are good reasons to publish the thin data ... is there any compelling reason not to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It's an attempt to disentangle concepts and find a way forward. Not all data is the same, so let's stop treating all data the same. We may not have to iterate repeatedly about thin data. Even the EWG's language wasn't always clear and specific in this area. Here's the question we will begin with next week: Should gTLD registration data be accessible for any purpose or only for specific purposes? "The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only. While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." What the EWG really meant was: * Give public, anonymous access to the THIN data. ("Basic data" as the EWG called it.) * Don't give every user the same anonymous public access to ("often inaccurate") gTLD CONTACT DATA. * Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
Only the Registry Operator (trademark owner) would be best positioned to include this authoritative data in the RDS/Whois output.
I'm sure there are other protocols much more suited to that sort of thing Are we now suggestion that the definition of "Registration Data" gets expanded to include any information any party to the registration wants to shove in there without paying for the storage/collection/management/maintenance/display costs ? Because if that's the case, I have ~28PB of encrypted data backups I'd like to put in RDS rather than on disks Rob
Hi Michael, On Wed, Dec 07, 2016 at 04:13:01PM -0500, Michael D. Palage wrote:
I appreciate Greg's historical context of Whois data primarily being for purposes of "contacting" the registrant of a domain name using those data fields with personally identifying information. However, I think introducing/relying upon the concept of "CONTACT DATA" as proposed by Greg while well intentioned will only lead to greater confusion.
If instead of "contact data" we want to call it "the flying monkey all-singing-and-dancing circus data", I don't care. I think Greg's point is that there are several different kinds of data here, and we could start with the little set that is unambiguously related to the domain _qua_ domain, and hammer out some agreement there. That would have the salubrious effects that we would have found some common ground, it would allow us to close coversations on some parts of the data, and it would allow us to acknowledge that there are at least two classes of data here. For that reason,
First Greg acknowledges that not ALL data other than the thin technical data falls within his CONTACT DATA definition
we might well acknowledge that there are at least two kinds of data we're talking about, and start with the first class. Then we could work on a second class. At some point, we'll run out of classes that people will be able to mention; we don't need to know in advance exactly how many there are. They're surely fewer than 30.
Second, the use of this terminology ignores the reality in the marketplace that Registrant data is widely relied upon to make legal determinations
What these different classes of data are used _for_ is an entirely different problem from what kinds of data they are. Those potential uses, indeed, are something we need to consider when asking under what circumstances a given datum may be disclosed, and to whom. But the use is not part of the definition of the kind of data.
"ICANN's WHOIS Lookup gives you the ability to lookup any generic domains, such as "icann.org" to find out the registered domain owner."
I do not believe one can argue from the premise that this is how things have always been done to the conclusion that it is how things _should_ be done.
So I think we stick to one of the first things I learned as a young engineer. Keep It Simple Stupid (KISS)
Agreed. And for that reason, we should start with the simple cases and forge some consensus there before we start with the hard cases. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Dear Mike: Thanks. And I think Andrew gets what I'm saying. "Should gTLD registration data be accessible for any purpose or only for specific purposes?" The question assumes we're talking about contact data. With thin data, I suggest that the question doesn't matter much -- none of that data's sensitive. The question only really matters when we're talking about contact data (PII). Note what I said: "This is not a proposal to publish thin data only." I'm simply wondering if everyone can agree that having an RDS is essential, and that publishing at least the thin data via it is essential for many valid and public purposes. Thin data may not satisfy all valid purposes, but requiring the world to get along without thin data seems untenable. Agreeing to this would be a step forward for the WG. Progress has been hard to find here, nearly a year in.... Then would come the more difficult discussion about contact data. Your observations do not invalidate my approach. I don't think my idea favors or endangers anyone's ability to argue their positions about the collection and publication of contact data (PII), nor does it endangers future innovation as far as I am aware. FWIW, I agree with you that the legal construct upon which the domain name system is based recognizes the Registrant and the Registrant Data that it provides. Let's not get too hung up on trademark, nexus, reseller, etc. data. These miscellaneous fields exist and we should be aware of them, and that future innovation (like inventing more) is possible. But also 99.5% of gTLD domains don't employ those extra fields at this time, and they're not a reason to torpedo anything at this stage. The general categories are useful. If we want to think of it as PII data versus not-PII data, that's a way to think of it too. Anyway, we are good engineers, and good engineers are aware of the corner cases while also keeping the big picture in mind. All best, --Greg ********************************** -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Wednesday, December 7, 2016 4:35 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Hi Michael, On Wed, Dec 07, 2016 at 04:13:01PM -0500, Michael D. Palage wrote:
I appreciate Greg's historical context of Whois data primarily being for purposes of "contacting" the registrant of a domain name using those data fields with personally identifying information. However, I think introducing/relying upon the concept of "CONTACT DATA" as proposed by Greg while well intentioned will only lead to greater confusion.
If instead of "contact data" we want to call it "the flying monkey all-singing-and-dancing circus data", I don't care. I think Greg's point is that there are several different kinds of data here, and we could start with the little set that is unambiguously related to the domain _qua_ domain, and hammer out some agreement there. That would have the salubrious effects that we would have found some common ground, it would allow us to close coversations on some parts of the data, and it would allow us to acknowledge that there are at least two classes of data here. For that reason,
First Greg acknowledges that not ALL data other than the thin technical data falls within his CONTACT DATA definition
we might well acknowledge that there are at least two kinds of data we're talking about, and start with the first class. Then we could work on a second class. At some point, we'll run out of classes that people will be able to mention; we don't need to know in advance exactly how many there are. They're surely fewer than 30.
Second, the use of this terminology ignores the reality in the marketplace that Registrant data is widely relied upon to make legal determinations
What these different classes of data are used _for_ is an entirely different problem from what kinds of data they are. Those potential uses, indeed, are something we need to consider when asking under what circumstances a given datum may be disclosed, and to whom. But the use is not part of the definition of the kind of data.
"ICANN's WHOIS Lookup gives you the ability to lookup any generic domains, such as "icann.org" to find out the registered domain owner."
I do not believe one can argue from the premise that this is how things have always been done to the conclusion that it is how things _should_ be done.
So I think we stick to one of the first things I learned as a young engineer. Keep It Simple Stupid (KISS)
Agreed. And for that reason, we should start with the simple cases and forge some consensus there before we start with the hard cases. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Please see my thoughts below. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Wednesday, December 07, 2016 5:24 PM To: Andrew Sullivan <ajs@anvilwalrusden.com>; gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Dear Mike: Thanks. And I think Andrew gets what I'm saying. "Should gTLD registration data be accessible for any purpose or only for specific purposes?" The question assumes we're talking about contact data. With thin data, I suggest that the question doesn't matter much -- none of that data's sensitive. The question only really matters when we're talking about contact data (PII). [Gomes, Chuck] I don't think I agree that the question assumes we are talking about contact data or that thin data is never sensitive. I believe that Andrew suggested the same thing. For example, is it possible for IP numbers to be sensitive? I also think that we may have to examine 'Other Data' (Data that is not thin or contact data). I would like to think that thin data and other data may be easier but we may still have to work on them. Note what I said: "This is not a proposal to publish thin data only." I'm simply wondering if everyone can agree that having an RDS is essential, and that publishing at least the thin data via it is essential for many valid and public purposes. Thin data may not satisfy all valid purposes, but requiring the world to get along without thin data seems untenable. Agreeing to this would be a step forward for the WG. Progress has been hard to find here, nearly a year in.... [Gomes, Chuck] I suspect that making the decision that having an RDS is essential may have to happen later. Don't get me wrong, it would be nice if we could agree on that now, but it may be premature to do that. We should certainly agree on what the valid and public purposes are first. I wouldn't be surprised if we came to conclusion that getting 'along without thin data seems untenable' but I believe we will have to specifically come to that conclusion in our deliberation. I do like Andrew's suggestion that we should start by focusing on think data. Then would come the more difficult discussion about contact data. Your observations do not invalidate my approach. I don't think my idea favors or endangers anyone's ability to argue their positions about the collection and publication of contact data (PII), nor does it endangers future innovation as far as I am aware. FWIW, I agree with you that the legal construct upon which the domain name system is based recognizes the Registrant and the Registrant Data that it provides. Let's not get too hung up on trademark, nexus, reseller, etc. data. These miscellaneous fields exist and we should be aware of them, and that future innovation (like inventing more) is possible. But also 99.5% of gTLD domains don't employ those extra fields at this time, and they're not a reason to torpedo anything at this stage. The general categories are useful. If we want to think of it as PII data versus not-PII data, that's a way to think of it too. Anyway, we are good engineers, and good engineers are aware of the corner cases while also keeping the big picture in mind. [Gomes, Chuck] The more immediate focus should be on the 99.5% but I think we will still have to cover the corner cases at least in a general sense. All best, --Greg ********************************** -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Wednesday, December 7, 2016 4:35 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean Hi Michael, On Wed, Dec 07, 2016 at 04:13:01PM -0500, Michael D. Palage wrote:
I appreciate Greg's historical context of Whois data primarily being for purposes of "contacting" the registrant of a domain name using those data fields with personally identifying information. However, I think introducing/relying upon the concept of "CONTACT DATA" as proposed by Greg while well intentioned will only lead to greater confusion.
If instead of "contact data" we want to call it "the flying monkey all-singing-and-dancing circus data", I don't care. I think Greg's point is that there are several different kinds of data here, and we could start with the little set that is unambiguously related to the domain _qua_ domain, and hammer out some agreement there. That would have the salubrious effects that we would have found some common ground, it would allow us to close coversations on some parts of the data, and it would allow us to acknowledge that there are at least two classes of data here. For that reason,
First Greg acknowledges that not ALL data other than the thin technical data falls within his CONTACT DATA definition
we might well acknowledge that there are at least two kinds of data we're talking about, and start with the first class. Then we could work on a second class. At some point, we'll run out of classes that people will be able to mention; we don't need to know in advance exactly how many there are. They're surely fewer than 30.
Second, the use of this terminology ignores the reality in the marketplace that Registrant data is widely relied upon to make legal determinations
What these different classes of data are used _for_ is an entirely different problem from what kinds of data they are. Those potential uses, indeed, are something we need to consider when asking under what circumstances a given datum may be disclosed, and to whom. But the use is not part of the definition of the kind of data.
"ICANN's WHOIS Lookup gives you the ability to lookup any generic domains, such as "icann.org" to find out the registered domain owner."
I do not believe one can argue from the premise that this is how things have always been done to the conclusion that it is how things _should_ be done.
So I think we stick to one of the first things I learned as a young engineer. Keep It Simple Stupid (KISS)
Agreed. And for that reason, we should start with the simple cases and forge some consensus there before we start with the hard cases. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
"Should gTLD registration data be accessible for any purpose or only for specific purposes?" The question assumes we're talking about contact data.
I don't think it does presuppose we're talking about _Registrant Information_ There are other data items _currently_ shown which may not be legal/permissable/acceptable/whatever, which have been "lumped" into "thin data" in this model
With thin data, I suggest that the question doesn't matter much -- none of that data's sensitive.
Lots of it is "sensitive" to varying degrees For example Reseller is very sensitive That data element ... * gives you an attack vector on my customer * it facilitates criminal activity and social engineering * it masssively increases the cold-calls, spam and junk they get * it makes them a potential target for who-Knows-what * it gives you a list of my customers (something almost no business would ever consider giving away,and may not legally be allowed to even talk about) and so on.
The question only really matters when we're talking about contact data (PII).
No the question matters about every single item which is suggested will be in "RDS"
I'm simply wondering if everyone can agree that having an RDS is essential
We don't have one currently, so it's hardly *essential* Maybe Useful ? Convenient ? Likely to do more good than harm overall ? The best description I can think of is that "RDS is likely to break anything that relies on WHOIS" ;)
and that publishing at least the thin data via it is essential for many valid and public purposes.
The making available of specified data elements to users of defined access/authorisation levels supports many purposes, the valid purposes being (TBD) Rob
I think this is a very useful suggestion. I think one of the problems with the EWG report is that it was so complex (yes, yes, representing a ton of hard work) that it was not clear exactly what we meant should be available to all. It is not the case that all parties wanted only the thin data you describe though, as Lisa has just elaborated. I know I am going to be annoyingly repetitive, but understanding the EWG report requires the annotated edition....which is not currently available. There are plenty of "but what about this" that need to be interjected whenever we pull isolated statements from that report. However, we soldier on.... Stephanie On 2016-12-07 09:55, Greg Aaron wrote:
Speaking of key concepts… people often say “registration data” when they really mean “contact data.” Being plain and specific here can help discussion in our group. The concept will come up in next week’s discussion.
There are basically two kinds of “registration data”. The first is called the*THIN DATA*. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain’s status(es) , created-updated-expiration dates, and nameservers. (https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial.
The second kind of registration data is *CONTACT DATA* – contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it’s ultimately supplied by the registrants. When people talk about “registration data accuracy” and “registration data validation” they are really talking about the accuracy of *CONTACT DATA*, not all “registration data.”
In the coming discussions, one approach could be: There are good reasons to publish the thin data … is there any compelling reason /not/ to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It’s an attempt to disentangle concepts and find a way forward. Not all data is the same, so let’s stop treating all data the same. We may not have to iterate repeatedly about thin data.
Even the EWG’s language wasn’t always clear and specific in this area. Here’s the question we will begin with next week:
/Should gTLD registration data be accessible for any purpose or only for specific purposes?/
/“The EWG unanimously recommends abandoning today’s WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only./
/While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use.”/
What the EWG really meant was:
·Give public, anonymous access to the THIN data. (“Basic data” as the EWG called it.)
·Don’t give every user the same anonymous public access to (“often inaccurate”) gTLD CONTACT DATA.
·Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only.
All best,
--Greg
**********************************
Greg Aaron
Vice-President, Product Management
iThreat Cyber Group / Cybertoolbelt.com
mobile: +1.215.858.2257
**********************************
The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi, First, let me start by agreeing very strongly with Greg that we can make some big gains by distinguishing between what he calls "thin data" (and what I think of as "name data" -- that is, data about the name _as such_) and "contact data" (what I think of as "registration data" -- that is, data about the registration: who did it, whom you can contact in the event of trouble, how to do so, and so on). In the interests of pushing forward along those lines, I'd like to take the position in this mail that the first class of these is one "tranche", and that each such field can be considered. Below I consider each such field and the arguments for and against competely unauthenticated, public access to it. I'm not actually sure I agree with Greg that it is not PII and noncontroversial, but I certainly agree that it is _less_ PII and way less controversial. On Wed, Dec 07, 2016 at 02:55:00PM +0000, Greg Aaron wrote:
called the THIN DATA. This is the basic data about a domain name registration:
the domain name,
For an RDS query about a domain name, this is the primary key by which the data must be fetched. Therefore, this is a necessary condition for an RDS at all. It must be included. Consequently, if someone disagrees that this is required data, that is someone who thinks we should not have an RDS. We should then have the discussion about whether we should have an RDS at all.
the sponsoring registrar name
For an RDS query about a domain name, this data is helpful to humans who are trying to track down the registration of the domain name. Since the point of an RDS is to allow someone who needs certain data about a registration to find that data, there may be an argument that being able to find out the source of the registration could be important. So, that is a reason to include the data. In addition, in a disrtibuted system (so, for instance, if we reverted to thin registries, which a technology like RDAP makes easy), it is necessary to get a referral to the _authoritative_ source of the data, and since the data actually comes from registrars rather than registries getting the sponsoring registrar is needed. (Whether the name is what's necessary for that is a different question; see below.) One could argue that this data should not be included because it is extraneous and could be looked up another way. One could argue that this data should not be included because it gives those who wish to do unauthorized transfers additional information in service of that transfer. Registrars could argue that they don't want their domains under management leaked (because this would allow people to harvest numbers and profile registrar operations).
and ID,
The arguments for and against here are the same as for the registrar name, except for the human consumption part. This ID is much preferable for automatic handling of the data.
the domain's status(es) ,
One could argue that this data needs to be public because one needs to know whether a name ought to be working on the Internet. One could argue that this data should not be included because most of it is not directly relevant to whether a domain name ought to be working. (For instance, whether an update is pending is not necessarily relevant to whether a name ought to resolve on the Internet right now.) Moreover, one could argue that at least some status values radiate information about what a registrant may have done, and also potentially supports attempts to game the registration system to obtain a domain name contrary to the interests of the previous registrant.
created- [date]
One can argue that this data needs to be public in order that one can understand whether the domain name one is querying about is in fact the name that is registered. For instance, if I want to know about example.com that was registered in 1998, and I get a response about a name created in 2017, then that tells me that the domain I am naming is not in fact the same name as the one that is currently registered. (A way to think about this is that the RDS is an atemporal database, but we often ask things that have an implicit temporal reference.) The counter-argument is that the above use is an indirect way of achieving a unique key, and the correct response would be to use unique IDs (perhaps Registry Object IDs or ROIDs) to uniquely identify the domain name rather than proxying by date.
updated- [date]
One can argue that this data needs to be public in order to aid in troubleshooting: if a name worked an hour ago and one can see the updated timestamp as having happened within that window, then the troubleshooter may infer that the update may be a factor in the failure. The counter-argument is that this data radiates information about actions taken on a domain name, and therefore could be used as part of an analysis that yields PII even if it is not PII itself.
expiration date[s]
One can argue that this data needs to be public in order to understand whether there is an operational threat to ongoing operations. One can argue that this data needs not to be public because it does not directly aid Internet operations, and can provide help to those who would attempt to game the registration system to "take over" a domain.
nameservers.
One can argue that this data needs to be public because it helps in troubleshooting failures: if a domain is not working and the DNS and registration data do not match, that may be the source of the probem. Follow-on efforts might include finding the gap between the name servers and registration system, waiting for the propagation time of the registry to pass, or whatever. Moreover, in principle if the registry and DNS are in harmony this data is already public, so there is no harm in including it in another public repository. It is hard for me to come up with an argument why this should not be public except for the case where someone thinks the RDDS is a bad idea in general. I hope this outline helps in narrowing the discussion about these data elements. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
the domain name, the sponsoring registrar name and ID,
are not controversial to me
the domain's status(es) , One could argue that this data should not be included because most of it is not directly relevant to whether a domain name ought to be working. (For instance, whether an update is pending is not necessarily relevant to whether a name ought to resolve on the Internet right now.) Moreover, one could argue that at least some status values radiate information about what a registrant may have done, and also potentially supports attempts to game the registration system to obtain a domain name contrary to the interests of the previous registrant.
Showing the status certainly increases the "criminal activity" regarding a domain name, and is a good reason not to include it.
created- [date] updated- [date] expiration date[s]
Lots of pros and cons for the dates - showing them increases abuse/malicious activity, allows for more social engineering, but they are useful. The downside is (as a Registar) we have more than once had phone calls along the lines of Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I forgot to write it down and dont have the email with me today, can you just read it out please" Us: "Who are you ?" Caller: "I'm (blah) working with (reads out name of registrant from whois)" // "I'm (name of registrant)" Us: "The account holder can get the details if needed from the client system" Caller: then usually tries some other tactic else hangs up or gets abusive - often tries to play the greed card "i'll take all my bisiness away and i know lots of your other customers" Us: *click*
nameservers.
And their IP addresses if self-referencing
Moreover, in principle if the registry and DNS are in harmony this data is already public, so there is no harm in including it in another public repository.
The 'harm' being : duplication = bad duplication = discrepancies duplication = mistakes as a general rule
It is hard for me to come up with an argument why this should not be public except for the case where someone thinks the RDDS is a bad idea in general.
The argument is that we're now getting RDS to deviate from "accurate" into "they might be the nameservers, but they might not, and even if they they were 30 minutes ago, they might not be anymore, I'm RDS not a shovel" responses. Do the NS and IP data help troubleshoot ? As they're neither authoritive nor necessarily reliable I doubt it, unless you dont know how to actually get the authoritive data, in which case what exactly are you able to troubleshoot ? Other data elements _currently_ required - I suggest we make this a new "group" as they're not "domain data" and they're not "registrant data" Registry Domain ID: Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: DNSSEC: Rob
Dear Rob: How does showing a domain's status fields "increase the 'criminal activity' regarding a domain name"? How does showing a domain's create and expiration dates "increase abuse/malicious activity"? As someone who's studied the criminal use of domains for many years, I have never seen or heard of any evidence of that. In fact, domain status and date information is important to people who investigate abuse or many want to make judgements about the trustworthiness of a domain. Best, --Greg -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Wednesday, December 7, 2016 8:42 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
the domain name, the sponsoring registrar name and ID,
are not controversial to me
the domain's status(es) , One could argue that this data should not be included because most of it is not directly relevant to whether a domain name ought to be working. (For instance, whether an update is pending is not necessarily relevant to whether a name ought to resolve on the Internet right now.) Moreover, one could argue that at least some status values radiate information about what a registrant may have done, and also potentially supports attempts to game the registration system to obtain a domain name contrary to the interests of the previous registrant.
Showing the status certainly increases the "criminal activity" regarding a domain name, and is a good reason not to include it.
created- [date] updated- [date] expiration date[s]
Lots of pros and cons for the dates - showing them increases abuse/malicious activity, allows for more social engineering, but they are useful. The downside is (as a Registar) we have more than once had phone calls along the lines of Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I forgot to write it down and dont have the email with me today, can you just read it out please" Us: "Who are you ?" Caller: "I'm (blah) working with (reads out name of registrant from whois)" // "I'm (name of registrant)" Us: "The account holder can get the details if needed from the client system" Caller: then usually tries some other tactic else hangs up or gets abusive - often tries to play the greed card "i'll take all my bisiness away and i know lots of your other customers" Us: *click*
nameservers.
And their IP addresses if self-referencing
Moreover, in principle if the registry and DNS are in harmony this data is already public, so there is no harm in including it in another public repository.
The 'harm' being : duplication = bad duplication = discrepancies duplication = mistakes as a general rule
It is hard for me to come up with an argument why this should not be public except for the case where someone thinks the RDDS is a bad idea in general.
The argument is that we're now getting RDS to deviate from "accurate" into "they might be the nameservers, but they might not, and even if they they were 30 minutes ago, they might not be anymore, I'm RDS not a shovel" responses. Do the NS and IP data help troubleshoot ? As they're neither authoritive nor necessarily reliable I doubt it, unless you dont know how to actually get the authoritive data, in which case what exactly are you able to troubleshoot ? Other data elements _currently_ required - I suggest we make this a new "group" as they're not "domain data" and they're not "registrant data" Registry Domain ID: Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: DNSSEC: Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Near the expiration dates, phony renewal notices are usually sent. Publishing the dates of creation or expiration makes calculating that easier. As for the status fields, I am guessing criminals would be able to deduce which domains are easier to steal if they can see which ones have a transfer lock enabled? Volker Am 08.12.2016 um 16:28 schrieb Greg Aaron:
Dear Rob:
How does showing a domain's status fields "increase the 'criminal activity' regarding a domain name"? How does showing a domain's create and expiration dates "increase abuse/malicious activity"?
As someone who's studied the criminal use of domains for many years, I have never seen or heard of any evidence of that. In fact, domain status and date information is important to people who investigate abuse or many want to make judgements about the trustworthiness of a domain.
Best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Wednesday, December 7, 2016 8:42 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
the domain name, the sponsoring registrar name and ID, are not controversial to me
the domain's status(es) , One could argue that this data should not be included because most of it is not directly relevant to whether a domain name ought to be working. (For instance, whether an update is pending is not necessarily relevant to whether a name ought to resolve on the Internet right now.) Moreover, one could argue that at least some status values radiate information about what a registrant may have done, and also potentially supports attempts to game the registration system to obtain a domain name contrary to the interests of the previous registrant. Showing the status certainly increases the "criminal activity" regarding a domain name, and is a good reason not to include it.
created- [date] updated- [date] expiration date[s] Lots of pros and cons for the dates - showing them increases abuse/malicious activity, allows for more social engineering, but they are useful.
The downside is (as a Registar) we have more than once had phone calls along the lines of
Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I forgot to write it down and dont have the email with me today, can you just read it out please" Us: "Who are you ?" Caller: "I'm (blah) working with (reads out name of registrant from whois)" // "I'm (name of registrant)" Us: "The account holder can get the details if needed from the client system" Caller: then usually tries some other tactic else hangs up or gets abusive - often tries to play the greed card "i'll take all my bisiness away and i know lots of your other customers" Us: *click*
nameservers. And their IP addresses if self-referencing
Moreover, in principle if the registry and DNS are in harmony this data is already public, so there is no harm in including it in another public repository. The 'harm' being : duplication = bad duplication = discrepancies duplication = mistakes as a general rule
It is hard for me to come up with an argument why this should not be public except for the case where someone thinks the RDDS is a bad idea in general. The argument is that we're now getting RDS to deviate from "accurate" into "they might be the nameservers, but they might not, and even if they they were 30 minutes ago, they might not be anymore, I'm RDS not a shovel" responses.
Do the NS and IP data help troubleshoot ? As they're neither authoritive nor necessarily reliable I doubt it, unless you dont know how to actually get the authoritive data, in which case what exactly are you able to troubleshoot ?
Other data elements _currently_ required - I suggest we make this a new "group" as they're not "domain data" and they're not "registrant data"
Registry Domain ID: Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: DNSSEC:
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ 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.
Expiration dates allow registrants to see when their names are expiring; a domain management task. Expiration dates make the domain name secondary market possible. Many parties use and benefit from the secondary market, including registrants, registrars, and registries. Create dates are important for assigning reputation to domain names and protecting consumers and Internet users. So those are some benefits that IMHO outweigh speculative security worries. Domains are often hijacked when the attacker gains control of the registrant account. And that allows the attacker to remove clientTransferProhibited status. So the status does not even matter. Every tool can be misused if someone tries hard enough. Domain names enable lots of crime. Is the response to that problem to make domain names very difficult and expensive to register? Or is making registration information available one proportional and reasonable response to the problem? All best, --Greg -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Volker Greimann Sent: Thursday, December 8, 2016 10:56 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean) Near the expiration dates, phony renewal notices are usually sent. Publishing the dates of creation or expiration makes calculating that easier. As for the status fields, I am guessing criminals would be able to deduce which domains are easier to steal if they can see which ones have a transfer lock enabled? Volker Am 08.12.2016 um 16:28 schrieb Greg Aaron:
Dear Rob:
How does showing a domain's status fields "increase the 'criminal activity' regarding a domain name"? How does showing a domain's create and expiration dates "increase abuse/malicious activity"?
As someone who's studied the criminal use of domains for many years, I have never seen or heard of any evidence of that. In fact, domain status and date information is important to people who investigate abuse or many want to make judgements about the trustworthiness of a domain.
Best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Wednesday, December 7, 2016 8:42 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
the domain name, the sponsoring registrar name and ID, are not controversial to me
the domain's status(es) , One could argue that this data should not be included because most of it is not directly relevant to whether a domain name ought to be working. (For instance, whether an update is pending is not necessarily relevant to whether a name ought to resolve on the Internet right now.) Moreover, one could argue that at least some status values radiate information about what a registrant may have done, and also potentially supports attempts to game the registration system to obtain a domain name contrary to the interests of the previous registrant. Showing the status certainly increases the "criminal activity" regarding a domain name, and is a good reason not to include it.
created- [date] updated- [date] expiration date[s] Lots of pros and cons for the dates - showing them increases abuse/malicious activity, allows for more social engineering, but they are useful.
The downside is (as a Registar) we have more than once had phone calls along the lines of
Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I forgot to write it down and dont have the email with me today, can you just read it out please" Us: "Who are you ?" Caller: "I'm (blah) working with (reads out name of registrant from whois)" // "I'm (name of registrant)" Us: "The account holder can get the details if needed from the client system" Caller: then usually tries some other tactic else hangs up or gets abusive - often tries to play the greed card "i'll take all my bisiness away and i know lots of your other customers" Us: *click*
nameservers. And their IP addresses if self-referencing
Moreover, in principle if the registry and DNS are in harmony this data is already public, so there is no harm in including it in another public repository. The 'harm' being : duplication = bad duplication = discrepancies duplication = mistakes as a general rule
It is hard for me to come up with an argument why this should not be public except for the case where someone thinks the RDDS is a bad idea in general. The argument is that we're now getting RDS to deviate from "accurate" into "they might be the nameservers, but they might not, and even if they they were 30 minutes ago, they might not be anymore, I'm RDS not a shovel" responses.
Do the NS and IP data help troubleshoot ? As they're neither authoritive nor necessarily reliable I doubt it, unless you dont know how to actually get the authoritive data, in which case what exactly are you able to troubleshoot ?
Other data elements _currently_ required - I suggest we make this a new "group" as they're not "domain data" and they're not "registrant data"
Registry Domain ID: Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: DNSSEC:
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ 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. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi, On Thu, Dec 08, 2016 at 04:30:13PM +0000, Greg Aaron wrote:
Expiration dates allow registrants to see when their names are expiring; a domain management task.
Well, yes, but registrants presumably have access to domain management though their registrar. However -- and this might be important -- the RDS expiration date (since it comes -- or should come -- from the registry) allows the registrant to check the data they get through their registrar. That could be valuable.
Expiration dates make the domain name secondary market possible. Many parties use and benefit from the secondary market, including registrants, registrars, and registries.
The secondary market, however, might also be a sign of inefficiency in the primary market. Perhaps that'd be a better thing to tackle. (I don't have an opinion. I'm just trying to expose the arguments in either direction about this field.)
Create dates are important for assigning reputation to domain names and protecting consumers and Internet users.
To be clear, if I understand you correctly you're arguing that the age of a domain below some period of time is a useful proxy indicator for the extent to which is has a history and therefore the extent to which it ought to be trusted, yes? That seems like an empirical question that could be validated. (I've heard conflicting claims about this, because the incremental increase in reputation that older domains get means that "bad guys" should just build a portfolio of older domain names to use for fraud.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Hi Greg, I am not disputing that, however does that information _really_ have to be public? In the past, the registry expiration dates even served to confuse the registrants due to the renew grace renewals performed by registries even though the registrar could still delete. Expiration dates can always be checked at your registrar. While they make registering domains on the drop easier, I am often hearing people complain that this service actually seen as a bad thing by some. I agree that created dates help determining trustworthyness, but that could be replaced by a domain freshness gauge, trusted certificates and other alternatives that would not give an exact date. Surely for consumer trust concerns, it is mostly irrelevant if a domain was registered four or five years ago and on which date? Transfer Status: That entirely depends on the mechanisms put in place by the registrar for removal. Some require two-factor authentification for this so even if someone got access to your registrar or mail account, he would not be able to transfer any domains out. I am not saying this data should be hidden, but I can imagine scenarios where it would not be needed. So we better make sure that when we say certain date is needed, that statement is correct. Volker Am 08.12.2016 um 17:30 schrieb Greg Aaron:
Expiration dates allow registrants to see when their names are expiring; a domain management task. Expiration dates make the domain name secondary market possible. Many parties use and benefit from the secondary market, including registrants, registrars, and registries. Create dates are important for assigning reputation to domain names and protecting consumers and Internet users. So those are some benefits that IMHO outweigh speculative security worries.
Domains are often hijacked when the attacker gains control of the registrant account. And that allows the attacker to remove clientTransferProhibited status. So the status does not even matter.
Every tool can be misused if someone tries hard enough. Domain names enable lots of crime. Is the response to that problem to make domain names very difficult and expensive to register? Or is making registration information available one proportional and reasonable response to the problem?
All best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Volker Greimann Sent: Thursday, December 8, 2016 10:56 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
Near the expiration dates, phony renewal notices are usually sent. Publishing the dates of creation or expiration makes calculating that easier.
As for the status fields, I am guessing criminals would be able to deduce which domains are easier to steal if they can see which ones have a transfer lock enabled?
Volker
Am 08.12.2016 um 16:28 schrieb Greg Aaron:
Dear Rob:
How does showing a domain's status fields "increase the 'criminal activity' regarding a domain name"? How does showing a domain's create and expiration dates "increase abuse/malicious activity"?
As someone who's studied the criminal use of domains for many years, I have never seen or heard of any evidence of that. In fact, domain status and date information is important to people who investigate abuse or many want to make judgements about the trustworthiness of a domain.
Best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Wednesday, December 7, 2016 8:42 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
the domain name, the sponsoring registrar name and ID, are not controversial to me
the domain's status(es) , One could argue that this data should not be included because most of it is not directly relevant to whether a domain name ought to be working. (For instance, whether an update is pending is not necessarily relevant to whether a name ought to resolve on the Internet right now.) Moreover, one could argue that at least some status values radiate information about what a registrant may have done, and also potentially supports attempts to game the registration system to obtain a domain name contrary to the interests of the previous registrant. Showing the status certainly increases the "criminal activity" regarding a domain name, and is a good reason not to include it.
created- [date] updated- [date] expiration date[s] Lots of pros and cons for the dates - showing them increases abuse/malicious activity, allows for more social engineering, but they are useful.
The downside is (as a Registar) we have more than once had phone calls along the lines of
Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I forgot to write it down and dont have the email with me today, can you just read it out please" Us: "Who are you ?" Caller: "I'm (blah) working with (reads out name of registrant from whois)" // "I'm (name of registrant)" Us: "The account holder can get the details if needed from the client system" Caller: then usually tries some other tactic else hangs up or gets abusive - often tries to play the greed card "i'll take all my bisiness away and i know lots of your other customers" Us: *click*
nameservers. And their IP addresses if self-referencing
Moreover, in principle if the registry and DNS are in harmony this data is already public, so there is no harm in including it in another public repository. The 'harm' being : duplication = bad duplication = discrepancies duplication = mistakes as a general rule
It is hard for me to come up with an argument why this should not be public except for the case where someone thinks the RDDS is a bad idea in general. The argument is that we're now getting RDS to deviate from "accurate" into "they might be the nameservers, but they might not, and even if they they were 30 minutes ago, they might not be anymore, I'm RDS not a shovel" responses.
Do the NS and IP data help troubleshoot ? As they're neither authoritive nor necessarily reliable I doubt it, unless you dont know how to actually get the authoritive data, in which case what exactly are you able to troubleshoot ?
Other data elements _currently_ required - I suggest we make this a new "group" as they're not "domain data" and they're not "registrant data"
Registry Domain ID: Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: DNSSEC:
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ 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.
_______________________________________________ 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.
I would draw a parallel between registry expiration dates and automobile insurance expiration dates. Only the insurance company and the insured know the expiry date, and in this case the LEA have the right to ask for proof of valid insurance. A parallel practice within the registrar/registry context would be no public information about either when registered or expiry date, but either an annual email to registrants (I get enough as it is trying to up sell me additional registrar services) or a couple of reminder emails prior to the expiry date. That, or a similar scheme, would allow the registrant to be keep informed - a service frequently not there now. It would also prevent the deceptive scam marketing emails that are thinly disguised "renewal" invoices and notices that are really registrar transfer notices or attempts to sell "related" domain names. Data that the registry and the registrant need for business should be shared between them, and nobody else. Let LEA use the laws for access (even if the laws are getting looser and looser <= another problem). Privacy services for the contact email would prevent the questionable value-added services offered for my domain names. I leave some WhoIS data public to toll for the scams that are out there, and there are a lot. A less knowledgeable domain name holder could be fleeced substantial sums for unwanted services, and a knowledgeable domain name holder could receive substantial spam email. Sam L NPOC/csih On 12/8/2016 11:58 AM, Volker Greimann wrote:
Hi Greg,
I am not disputing that, however does that information _really_ have to be public? In the past, the registry expiration dates even served to confuse the registrants due to the renew grace renewals performed by registries even though the registrar could still delete.
Expiration dates can always be checked at your registrar.
While they make registering domains on the drop easier, I am often hearing people complain that this service actually seen as a bad thing by some.
I agree that created dates help determining trustworthyness, but that could be replaced by a domain freshness gauge, trusted certificates and other alternatives that would not give an exact date. Surely for consumer trust concerns, it is mostly irrelevant if a domain was registered four or five years ago and on which date?
Transfer Status: That entirely depends on the mechanisms put in place by the registrar for removal. Some require two-factor authentification for this so even if someone got access to your registrar or mail account, he would not be able to transfer any domains out.
I am not saying this data should be hidden, but I can imagine scenarios where it would not be needed. So we better make sure that when we say certain date is needed, that statement is correct.
Volker
Am 08.12.2016 um 17:30 schrieb Greg Aaron:
Expiration dates allow registrants to see when their names are expiring; a domain management task. Expiration dates make the domain name secondary market possible. Many parties use and benefit from the secondary market, including registrants, registrars, and registries. Create dates are important for assigning reputation to domain names and protecting consumers and Internet users. So those are some benefits that IMHO outweigh speculative security worries.
Domains are often hijacked when the attacker gains control of the registrant account. And that allows the attacker to remove clientTransferProhibited status. So the status does not even matter.
Every tool can be misused if someone tries hard enough. Domain names enable lots of crime. Is the response to that problem to make domain names very difficult and expensive to register? Or is making registration information available one proportional and reasonable response to the problem?
All best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Volker Greimann Sent: Thursday, December 8, 2016 10:56 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
Near the expiration dates, phony renewal notices are usually sent. Publishing the dates of creation or expiration makes calculating that easier.
As for the status fields, I am guessing criminals would be able to deduce which domains are easier to steal if they can see which ones have a transfer lock enabled?
Volker
Am 08.12.2016 um 16:28 schrieb Greg Aaron:
Dear Rob:
How does showing a domain's status fields "increase the 'criminal activity' regarding a domain name"? How does showing a domain's create and expiration dates "increase abuse/malicious activity"?
As someone who's studied the criminal use of domains for many years, I have never seen or heard of any evidence of that. In fact, domain status and date information is important to people who investigate abuse or many want to make judgements about the trustworthiness of a domain.
Best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Wednesday, December 7, 2016 8:42 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
the domain name, the sponsoring registrar name and ID, are not controversial to me
the domain's status(es) , One could argue that this data should not be included because most of it is not directly relevant to whether a domain name ought to be working. (For instance, whether an update is pending is not necessarily relevant to whether a name ought to resolve on the Internet right now.) Moreover, one could argue that at least some status values radiate information about what a registrant may have done, and also potentially supports attempts to game the registration system to obtain a domain name contrary to the interests of the previous registrant. Showing the status certainly increases the "criminal activity" regarding a domain name, and is a good reason not to include it.
created- [date] updated- [date] expiration date[s] Lots of pros and cons for the dates - showing them increases abuse/malicious activity, allows for more social engineering, but they are useful.
The downside is (as a Registar) we have more than once had phone calls along the lines of
Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I forgot to write it down and dont have the email with me today, can you just read it out please" Us: "Who are you ?" Caller: "I'm (blah) working with (reads out name of registrant from whois)" // "I'm (name of registrant)" Us: "The account holder can get the details if needed from the client system" Caller: then usually tries some other tactic else hangs up or gets abusive - often tries to play the greed card "i'll take all my bisiness away and i know lots of your other customers" Us: *click*
nameservers. And their IP addresses if self-referencing
Moreover, in principle if the registry and DNS are in harmony this data is already public, so there is no harm in including it in another public repository. The 'harm' being : duplication = bad duplication = discrepancies duplication = mistakes as a general rule
It is hard for me to come up with an argument why this should not be public except for the case where someone thinks the RDDS is a bad idea in general. The argument is that we're now getting RDS to deviate from "accurate" into "they might be the nameservers, but they might not, and even if they they were 30 minutes ago, they might not be anymore, I'm RDS not a shovel" responses.
Do the NS and IP data help troubleshoot ? As they're neither authoritive nor necessarily reliable I doubt it, unless you dont know how to actually get the authoritive data, in which case what exactly are you able to troubleshoot ?
Other data elements _currently_ required - I suggest we make this a new "group" as they're not "domain data" and they're not "registrant data"
Registry Domain ID: Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: DNSSEC:
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ 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.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- ------------------------------------------------ "It is a disgrace to be rich and honoured in an unjust state" -Confucius 邦有道，贫且贱焉，耻也。邦无道，富且贵焉，耻也 ------------------------------------------------ Dr Sam Lanfranco (Prof Emeritus & Senior Scholar) Econ, York U., Toronto, Ontario, CANADA - M3J 1P3 email: Lanfran@Yorku.ca Skype: slanfranco blog: https://samlanfranco.blogspot.com Phone: +1 613-476-0429 cell: +1 416-816-2852
Hi Sam
but either an annual email to registrants (I get enough as it is trying to up sell me additional registrar services) or a couple of reminder emails prior to the expiry date.
That, or a similar scheme, would allow the registrant to be keep informed - a service frequently not there now
Those are already requirements and policies - if you are aware of registrars not sending annual wdrp reminders, pre-expiry notices and post expiry notices, feel free to report the registrar to compliance. Registrants are "entitled" to the masses of mandated communications (and aren't even allowed to opt-out which itself is a constant cause of complaints, and possibly even illegal in some jurisdictions) Rob
On 8 Dec 2016, at 11:30, Greg Aaron wrote:
Expiration dates allow registrants to see when their names are expiring; a domain management task. Expiration dates make the domain name secondary market possible. Many parties use and benefit from the secondary market, including registrants, registrars, and registries. Create dates are important for assigning reputation to domain names and protecting consumers and Internet users. So those are some benefits that IMHO outweigh speculative security worries.
I want to push back a little bit on some of these, primarily because I want to be careful about the precedent we’re setting. I think that expiration date and registrants is an issue for the registrant to resolve with their “registrar”. It is probably information that the registry has and as such the registry could publish it, assuming the registry has a publication system (see what I did there?), but why transfer that burden? Wouldn’t registrars prefer to strengthen their relationship with a registrant? I believe we need to be careful about the secondary market argument. That argument assumes facts not in evidence, i.e., this is how it works today and therefore it should continue to work that way. We need another reason than just the secondary market. The problem is, if the secondary market is a justification for this data, then what data would not be justified by the secondary market? While I agree that create dates are a leading indicator of domain reputation, I know that you also know this is trivial to game if a malefactor were so inclined. So, there might be a “security argument” that could be made about create dates but I’m not sure I would celebrate that fact, i.e., I’m reserving my opinion on whether or not that is compelling. Jim
Domains are often hijacked when the attacker gains control of the registrant account. And that allows the attacker to remove clientTransferProhibited status. So the status does not even matter.
Every tool can be misused if someone tries hard enough. Domain names enable lots of crime. Is the response to that problem to make domain names very difficult and expensive to register? Or is making registration information available one proportional and reasonable response to the problem?
All best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Volker Greimann Sent: Thursday, December 8, 2016 10:56 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
Near the expiration dates, phony renewal notices are usually sent. Publishing the dates of creation or expiration makes calculating that easier.
As for the status fields, I am guessing criminals would be able to deduce which domains are easier to steal if they can see which ones have a transfer lock enabled?
Volker
Am 08.12.2016 um 16:28 schrieb Greg Aaron:
Dear Rob:
How does showing a domain's status fields "increase the 'criminal activity' regarding a domain name"? How does showing a domain's create and expiration dates "increase abuse/malicious activity"?
As someone who's studied the criminal use of domains for many years, I have never seen or heard of any evidence of that. In fact, domain status and date information is important to people who investigate abuse or many want to make judgements about the trustworthiness of a domain.
Best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Wednesday, December 7, 2016 8:42 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
the domain name, the sponsoring registrar name and ID, are not controversial to me
the domain's status(es) , One could argue that this data should not be included because most of it is not directly relevant to whether a domain name ought to be working. (For instance, whether an update is pending is not necessarily relevant to whether a name ought to resolve on the Internet right now.) Moreover, one could argue that at least some status values radiate information about what a registrant may have done, and also potentially supports attempts to game the registration system to obtain a domain name contrary to the interests of the previous registrant. Showing the status certainly increases the "criminal activity" regarding a domain name, and is a good reason not to include it.
created- [date] updated- [date] expiration date[s] Lots of pros and cons for the dates - showing them increases abuse/malicious activity, allows for more social engineering, but they are useful.
The downside is (as a Registar) we have more than once had phone calls along the lines of
Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I forgot to write it down and dont have the email with me today, can you just read it out please" Us: "Who are you ?" Caller: "I'm (blah) working with (reads out name of registrant from whois)" // "I'm (name of registrant)" Us: "The account holder can get the details if needed from the client system" Caller: then usually tries some other tactic else hangs up or gets abusive - often tries to play the greed card "i'll take all my bisiness away and i know lots of your other customers" Us: *click*
nameservers. And their IP addresses if self-referencing
Moreover, in principle if the registry and DNS are in harmony this data is already public, so there is no harm in including it in another public repository. The 'harm' being : duplication = bad duplication = discrepancies duplication = mistakes as a general rule
It is hard for me to come up with an argument why this should not be public except for the case where someone thinks the RDDS is a bad idea in general. The argument is that we're now getting RDS to deviate from "accurate" into "they might be the nameservers, but they might not, and even if they they were 30 minutes ago, they might not be anymore, I'm RDS not a shovel" responses.
Do the NS and IP data help troubleshoot ? As they're neither authoritive nor necessarily reliable I doubt it, unless you dont know how to actually get the authoritive data, in which case what exactly are you able to troubleshoot ?
Other data elements _currently_ required - I suggest we make this a new "group" as they're not "domain data" and they're not "registrant data"
Registry Domain ID: Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: DNSSEC:
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ 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.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Expiration dates allow registrants to see when their names are expiring; a domain management task.
Domain management is done by Registrants at their Registrar, who will know the dates (and indeed should be the authoritive source for those dates) - the domain can't be "managed" anywhere else or (in most circumstances) by anyone else Dates are not necessarily "correct" on a whois (so for 1/12th of the year tend to confuse more than they help) due to registrar auto renewal and so on And in my experience very few registrants understand whois, and the majority of those that do at least "get it" incorrectly use 3rd party sites, cached database copies, random google links, clickbaits etc and not the registry/registrar version anyway - so the potential for mistakes and misunderstandings grows exponentially Let's remember most of the WG are not "ordinary internet users" or even "common registrants" we all "get it" but we're an infinitesimally small minority.
Expiration dates make the domain name secondary market possible.
Yes, I agree. Unfortunately we're into playing the "risk vs reward" game I'd rather not see the WG go with the UK Gov't view - that the potential to maybe catch 1 criminal is worth taking away the civil liberties of 65 million law abiding individuals :(
Create dates are important for assigning reputation to domain names and protecting consumers and Internet users.
I must have missed the RFC for the Internet Nanny protocol, thus am not sure how reputation of domains works ;) Presumably these are 3rd party "services" which are making money out of the registries', registrars' and registrants' data they are harvesting for free from whois ?
Domains are often hijacked when the attacker gains control of the registrant account.
Yes, and that would be massively more difficult if the Registrar data wasn't public, but I do agree that is a small enough %age to warrant the inclusion of registrar details if we have any RDS output, benefits outweighing risks, but they're specific and targetted attacks
So the status does not even matter.
It certainly does. Is a car more likely to get stolen because it's left unlocked, or because it exactly matches a specific item on a "shopping list" ? It's functionally equivalent to the difference between broadcasting the state of your front door lock at all times, and having a locked door kicked-in during your absence If there was a global+accurate list of which homes were "open", who do you think benefits from that ? People that break into homes, people that market security systems, people who want to illegally squat, a family member who has forgotten their keys - the list is practically endless - and again it's the risk vs reward The only time items have ever been stolen from my garage was the one time I got distracted to sign for a parcel delivery as I was wheeling out my bike, and rode off without putting the padlock back on Simply put more data = better targetting (for good or ill)
Domain names enable lots of crime.
Do they ? Really ? Of course I agree that *some* crimes may involve domain names in some way. Everything can be, will be and is used in a crime at some point. Lots of crimes involve a vehicle, but the ownership details, dealership details, manufacturer details and so on of every vehicle in existence isn't "public" for people to do what they like with - I'd suggest that if it were it would increase crime not reduce it. Can "those that *need* to know" get some of that data - yes, probably rightly, although the amount of data and the list of accessors is severely limited
Is the response to that problem to make domain names very difficult and expensive to register? Or is making registration information available one proportional and reasonable response to the problem?
If they are the only 2 answers available to choose from , I clearly haven't understood the question. What we need is sadly not do-able. All data about my-domain.ext should be locked away in an impenetrable opaque bubble, and legitimate requests for select information can be allowed temporary view-only access, all external copies of it blow up at a specific time, it can't be further shared, the view is logged, the data can be remote detonated, further / repeat access recalled at any point etc In fact what we need is that for all data about anything with appropriate interconnectors for it all Sadly 40 million years ago a caveman realised that you could paint on a wall and permanent data records, sharing, public viewing etc have existed ever since :( Rob
How does showing a domain's status fields "increase the 'criminal activity' regarding a domain name"?
Simply that domain thieves have learned to concentrate on trying fake-transfers only with a domain that says status "ok". Almost the only use of our fax in recent years have been dodgy transfer attempts on domains which are not locked, so showing it in my experience is inviting fraud/criminal-activity etc I've also been one of those taking calls from people attempting "social engineering" to gain access to or control over a domain, and those domains are invariablly shown as "ok" due to the status flags
How does showing a domain's create and expiration dates "increase abuse/malicious activity"?
Expiry date gets used by the masses of scum who send fake notices of renewal, fake directory listings. Creation date is used by mass spammers for SEO offers, web-design offers and so on - the amount of those on domains less than a year old is significantly higher than on established domains Similarly we've had numerous registrants scammed (and just as many complaining) because they register a domain, and then get bombarded by fraudsters with offers of other domains etc - whilst I know a lot of that is scammers utilising the zone files and determining the changes, in a considerable number of cases the creation date is used/mentioned A relatively common one is for a registrant to get a call which starts like "Hi we're from (registrar) [outright lie] and the domain (domain-name) you registered on (creation date) is held with a question over payment, can you just confirm the method you used ...."
As someone who's studied the criminal use of domains for many years,
We see almost no "criminal use" of domains - mostly we do see criminal attempts to get hold of domains (through theft or payment fraud), and abuse of services that a domain is being used to point at
In fact, domain status and date information is important to people who investigate abuse or many want to make judgements about the trustworthiness of a domain.
Yes, something that is (in my experience) to the overall detriment of the Registrant and Registrar is "useful" to A-N-Other-party (whether that is valid/legal/whatever or not) - this is always going to be the issue with "data" Rob
+1 to Greg's approach. Not to make too fine a point, the EWG categorised registration data by supplier as well in an effort to make the case for restrictions easier to glean. Certainly easier to follow but did not have the effect some of us were expecting. The precondition was to accept the rationale for collecting and curating the data in the first place. I am yet persuaded that most of this data is not contentious and the call for consensus on those categories and their elements should be exectued now. Then spend the time arguing about the relatively fewer contentious pieces towards a sensible conclusion on collection, storage and access. -Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Wed, Dec 7, 2016 at 9:55 AM, Greg Aaron <gca@icginc.com> wrote:
Speaking of key concepts… people often say “registration data” when they really mean “contact data.” Being plain and specific here can help discussion in our group. The concept will come up in next week’s discussion.
There are basically two kinds of “registration data”. The first is called the* THIN DATA*. This is the basic data about a domain name registration: the domain name, the sponsoring registrar name and ID, the domain’s status(es) , created-updated-expiration dates, and nameservers. ( https://whois.icann.org/en/what-are-thick-and-thin-entries ) This data is factual, accurate, is not personally identifiable, and I think is completely noncontroversial.
The second kind of registration data is *CONTACT DATA* – contact names, postal and email addresses, phone numbers. Contact data raises issues of privacy and data protection. Contact data can be (and regularly is) inaccurate because it’s ultimately supplied by the registrants. When people talk about “registration data accuracy” and “registration data validation” they are really talking about the accuracy of *CONTACT DATA*, not all “registration data.”
In the coming discussions, one approach could be: There are good reasons to publish the thin data … is there any compelling reason *not* to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It’s an attempt to disentangle concepts and find a way forward. Not all data is the same, so let’s stop treating all data the same. We may not have to iterate repeatedly about thin data.
Even the EWG’s language wasn’t always clear and specific in this area. Here’s the question we will begin with next week:
*Should gTLD registration data be accessible for any purpose or only for specific purposes?*
*“The EWG unanimously recommends abandoning today’s WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift to a next-generation RDS that collects, validates and discloses gTLD registration data for permissible purposes only.*
*While basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use.”*
What the EWG really meant was:
· Give public, anonymous access to the THIN data. (“Basic data” as the EWG called it.)
· Don’t give every user the same anonymous public access to (“often inaccurate”) gTLD CONTACT DATA.
· Shift to an RDS that collects, validates and discloses gTLD CONTACT DATA for permissible purposes only.
All best,
--Greg
**********************************
Greg Aaron
Vice-President, Product Management
iThreat Cyber Group / Cybertoolbelt.com
mobile: +1.215.858.2257 <(215)%20858-2257>
**********************************
The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On 2016-12-07 14:55, Greg Aaron wrote:
Speaking of key concepts… people often say "registration data" when they really mean "contact data."
I find that what they really mean is generally "stuff I see on a whois lookup" which is all sorts of data * data about registrar * data about registration * data about registrant * data about registry * data about regulator * T&Cs etc
the THIN DATA. This data is factual
Sometimes
accurate,
At a certain point-in-time, dependant on the source you are obtaining it from
is not personally identifiable,
It could be possible to identify a person from the data, but it's not as straightforward as printing their name & address
and I think is completely noncontroversial.
Several items in what you're grouping as "thin data" are definately controversial, and a regular cause of problems
The second kind of registration data is CONTACT DATA
Yes
In the coming discussions, one approach could be: There are good reasons to publish the thin data … is there any compelling reason _not_ to publish it?
Reasons not to ? * it's unnecessary to the functioning of the domain/internet * the EWG said not to make it all freely available * select items shouldn't necessarily be mandated / public * it costs time/effort/money to collect, store, display etc * it's a security risk and so on There are good reasons for _some_ of what you refer to as thin data being available (registrar name for example) and other elements to authorised viewers on a need-to-know Perhaps anon/open data access should be to the minimum elements necessary, with anything else being subject to knowing * who they are * what data they're authorised to see * what exactly that data is going to be used for * agreement to be slapped if they misuse or redistribute the data
_"The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data.
100% behind that :)
_While basic data would remain publicly available,
So ideally we just need to identify "basic data" which I'd suggest is * domain name * domain registrar
the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use."_
Yes, everything else comes under "why do you need to know" Rob
Regarding Rob's reasons against publishing thin data: * "it's unnecessary to the functioning of the domain/internet." This is not the razor to be used here. A domain name can function if there's no RDS at all. This WG would look foolish in the eyes of the world if it decided to abolish WHOIS and any successor RDSes. Of course there are good reasons to have an RDS. The question is what data should be published through it. * "the EWG said not to make it all freely available". No, not correct. The EWG said the thin data should be freely available, PLUS Registrant email address too. See pages 46 and 133-134 of the EWG Final Report. * "it costs time/effort/money to collect, store, display etc." Storing, transmitting, and publishing data is the core job of a registry; it is literally their reason for being. (And registrars too, until .COM and .NET go thick.) They build the cost of doing it into the prices they charge. If one does not want to bear the costs of storing, transmitting, and publishing data, then one should avoid the registry business. * "it's a security risk." Some argue that it is a security risk to publish certain kinds of personal data. Is an RDS itself a security risk? A bank is a security risk, but that does not mean we should not have banks. We have good reasons to have banks, and they outweigh the risks. **************** -----Original Message----- From: Rob Golding [mailto:rob.golding@astutium.com] Sent: Wednesday, December 7, 2016 7:20 PM To: Greg Aaron <gca@icginc.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean On 2016-12-07 14:55, Greg Aaron wrote:
Speaking of key concepts… people often say "registration data" when they really mean "contact data."
I find that what they really mean is generally "stuff I see on a whois lookup" which is all sorts of data * data about registrar * data about registration * data about registrant * data about registry * data about regulator * T&Cs etc
the THIN DATA. This data is factual
Sometimes
accurate,
At a certain point-in-time, dependant on the source you are obtaining it from
is not personally identifiable,
It could be possible to identify a person from the data, but it's not as straightforward as printing their name & address
and I think is completely noncontroversial.
Several items in what you're grouping as "thin data" are definately controversial, and a regular cause of problems
The second kind of registration data is CONTACT DATA
Yes
In the coming discussions, one approach could be: There are good reasons to publish the thin data … is there any compelling reason _not_ to publish it?
Reasons not to ? * it's unnecessary to the functioning of the domain/internet * the EWG said not to make it all freely available * select items shouldn't necessarily be mandated / public * it costs time/effort/money to collect, store, display etc * it's a security risk and so on There are good reasons for _some_ of what you refer to as thin data being available (registrar name for example) and other elements to authorised viewers on a need-to-know Perhaps anon/open data access should be to the minimum elements necessary, with anything else being subject to knowing * who they are * what data they're authorised to see * what exactly that data is going to be used for * agreement to be slapped if they misuse or redistribute the data
_"The EWG unanimously recommends abandoning today's WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data.
100% behind that :)
_While basic data would remain publicly available,
So ideally we just need to identify "basic data" which I'd suggest is * domain name * domain registrar
the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use."_
Yes, everything else comes under "why do you need to know" Rob
Regarding Rob's reasons against publishing thin data: * "it's unnecessary to the functioning of the domain/internet." This is not the razor to be used here.
Yes, it might be "nice" or "convenient" or for various-use-cases "helpful" - which may be considered reasons to publish the data, but this does not make publishing in any way *necessary*
A domain name can function if there's no RDS at all.
Agreed :)
This WG would look foolish in the eyes of the world if it decided to abolish WHOIS and any successor RDSes.
I doubt that will be the final outcome, but it would be a very valid "solution" to the "whois problem" that has caused 15 years of working groups. Various people-with-an-agenda think whois is not fit for *their purpose* so one solution would be to put it out of its' misery and scrap it !
* "the EWG said not to make it all freely available". No, not correct. The EWG said the thin data should be freely available,
That wasn't my understanding/reading (or what was quoted in the email I replied to), there was mention of
_While basic data would remain publicly available,
And I said ...
So ideally we just need to identify "basic data" which I'd suggest is * domain name * domain registrar
That's all.
* "it costs time/effort/money to collect, store, display etc." Storing, transmitting, and publishing data is the core job of a registry;
In a convoluted manner, sort of. The primary task of a registry is to maintain the master list of domain names in that tld and provide nameservers for those domains to allow the referral of ns lookups. Plenty of them publish basically nothing for whois, so many do not see it as a "core" feature - a contractual requirement to answer to a protocol maybe, but not a core aspect of their function
it is literally their reason for being. (And registrars too, until .COM and .NET go thick.)
If you asked every registrar and registry, I seriously doubt you'll get any who would say operating a WHOIS service was their "reason for being" It's a given that: More data = more cost More publishing = more cost More access = more cost
They build the cost of doing it into the prices they charge.
To an extent, we're already incorrectly charging the registrant, who doesn't want whois anyway. RDS kind-of implies centralising, and that will be more/additional/new costs - so at the least provides an opportunity to switch to a PPV model.
* "it's a security risk." Some argue that it is a security risk to publish certain kinds of personal data. Is an RDS itself a security risk? A bank is a security risk, but that does not mean we should not have banks. We have good reasons to have banks, and they outweigh the risks.
The question was about publishing data - if you dont have that data there is no risk and if you dont publish that data there is less risk. Why do you think banks dont publish all the numbers and names of their account holders - because doing so would be considered a massive security risk (to themselves and their account holders) Do they have that data - yes, so there is some risk. And the risks are magnified if it's centralised - imagine if there was 1 bank that had every possible account holders details - and then the regulator said "publish it" ! As I said ...
Perhaps anon/open data access should be to the minimum elements necessary, with anything else being subject to knowing * who they are * what data they're authorised to see * what exactly that data is going to be used for * agreement to be slapped if they misuse or redistribute the data
Which I think is entirely in-line with what the EWG report says. TL:DR; # I doubt we'll get consensus on just turning whois off and suggesting no RDS, but I promise to buy the 1st round of Champagne for us all to celebrate if it is the WG final decision # what is "stored" needs to be only what is absolutely necessary and can't be obtained elsewhere or by another method, defaulting to 'nothing' # what is "published" from what is stored needs to be as close to nothing as possible by default, and then for each thing stored, only what is absolutely necessary for that accesser and that access reason (with appropriate controls and audits applicable to handling that) Rob
On 7 Dec 2016, at 9:55, Greg Aaron wrote:
In the coming discussions, one approach could be: There are good reasons to publish the thin data … is there any compelling reason _not_ to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It’s an attempt to disentangle concepts and find a way forward. Not all data is the same, so let’s stop treating all data the same. We may not have to iterate repeatedly about thin data.
I agree with the principle that we should tease apart “registration data” into a few different categories. The discussion in the rest of this thread has been focused on that and I’ll state I support it. My current view is that there are at least three categories of data: PII (e.g., contact information), operational and explicitly not-PII (e.g., registrar ID and NS records), and other (e.g., registries with specific requirements). I have two concerns with this discussion though. First, we keep talking about “publishing” data. Greg is careful to point out he’s not talking about publishing, per se, but he doesn’t mention what we are talking about. Second, given we understand our data (which is a reason to categorize it) there are at least three topics to talk about with respect to that data. 1. Why do we care about this data, or perhaps, what is the purpose of the data? The answer to these questions is both critical and essential. They will drive the answer to the next two questions. In my opinion, without an answer to these questions (eventually, if not first or early in our process), discussions about the next two topics will never come to a conclusion. By the way, also my opinion, any answer that somehow embodies a reference to the existing system and service is irrelevant. 2. What are the data collection requirements? This includes who, what, where, why, and how, including storage. 3. What are the publication requirements? Might be zero. Greg suggests above that we could approach the problem of publication in some cases by answering the following question, “Is there any compelling reason not to publish it?” I will object to this. This is never the right question. The right question is always, “Why publish it?” You can’t publish it if you don’t collect it and you don’t collect it if you don’t have a need for it. All questions must be answered in the positive. Otherwise what’s the point of our discussion? The answer will always default to be collect everything and publish everything, and then let the lawyers fight about what’s public. Jim
I look at sensitive data as data that exposes a threat to the registrant - this is also contact information. Other records like the NS records may not be sensitive data. Third parties pick this data and use it for spam. This is the point where I think restricted Access is important. Where there is need for the data the registrant should be asked for consent that the data be shared. Daniel Regards Nanghaka Daniel K. Executive Director - ILICIT Africa / Council Member - FOSSFA / Community Lead - ISOC Uganda Chapter Mobile +256 772 898298 (Uganda) Skype: daniel.nanghaka ----------------------------------------- *"Working for Africa" * ----------------------------------------- On Thu, Dec 8, 2016 at 10:11 PM, James Galvin <jgalvin@afilias.info> wrote:
On 7 Dec 2016, at 9:55, Greg Aaron wrote:
In the coming discussions, one approach could be: There are good reasons
to publish the thin data … is there any compelling reason _not_ to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It’s an attempt to disentangle concepts and find a way forward. Not all data is the same, so let’s stop treating all data the same. We may not have to iterate repeatedly about thin data.
I agree with the principle that we should tease apart “registration data” into a few different categories. The discussion in the rest of this thread has been focused on that and I’ll state I support it. My current view is that there are at least three categories of data: PII (e.g., contact information), operational and explicitly not-PII (e.g., registrar ID and NS records), and other (e.g., registries with specific requirements).
I have two concerns with this discussion though. First, we keep talking about “publishing” data. Greg is careful to point out he’s not talking about publishing, per se, but he doesn’t mention what we are talking about.
Second, given we understand our data (which is a reason to categorize it) there are at least three topics to talk about with respect to that data.
1. Why do we care about this data, or perhaps, what is the purpose of the data? The answer to these questions is both critical and essential. They will drive the answer to the next two questions. In my opinion, without an answer to these questions (eventually, if not first or early in our process), discussions about the next two topics will never come to a conclusion. By the way, also my opinion, any answer that somehow embodies a reference to the existing system and service is irrelevant.
2. What are the data collection requirements? This includes who, what, where, why, and how, including storage.
3. What are the publication requirements? Might be zero. Greg suggests above that we could approach the problem of publication in some cases by answering the following question, “Is there any compelling reason not to publish it?” I will object to this. This is never the right question. The right question is always, “Why publish it?” You can’t publish it if you don’t collect it and you don’t collect it if you don’t have a need for it.
All questions must be answered in the positive. Otherwise what’s the point of our discussion? The answer will always default to be collect everything and publish everything, and then let the lawyers fight about what’s public.
Jim
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On 8 Dec 2016, at 17:28, DANIEL NANGHAKA wrote:
I look at sensitive data as data that exposes a threat to the registrant - this is also contact information.
This is probably too broad a definition. I suspect a case could be made that most if not all data is a potential threat to a registrant because in our world of big data aggregation and correlation are always a threat. I don’t have a suggestion just yet for how to restrict this but it is otherwise a possible starting point for discussions. Jim
Other records like the NS records may not be sensitive data.
Third parties pick this data and use it for spam. This is the point where I think restricted Access is important. Where there is need for the data the registrant should be asked for consent that the data be shared.
Daniel
Regards Nanghaka Daniel K. Executive Director - ILICIT Africa / Council Member - FOSSFA / Community Lead - ISOC Uganda Chapter Mobile +256 772 898298 (Uganda) Skype: daniel.nanghaka
----------------------------------------- *"Working for Africa" * -----------------------------------------
On Thu, Dec 8, 2016 at 10:11 PM, James Galvin <jgalvin@afilias.info> wrote:
On 7 Dec 2016, at 9:55, Greg Aaron wrote:
In the coming discussions, one approach could be: There are good reasons
to publish the thin data … is there any compelling reason _not_ to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It’s an attempt to disentangle concepts and find a way forward. Not all data is the same, so let’s stop treating all data the same. We may not have to iterate repeatedly about thin data.
I agree with the principle that we should tease apart “registration data” into a few different categories. The discussion in the rest of this thread has been focused on that and I’ll state I support it. My current view is that there are at least three categories of data: PII (e.g., contact information), operational and explicitly not-PII (e.g., registrar ID and NS records), and other (e.g., registries with specific requirements).
I have two concerns with this discussion though. First, we keep talking about “publishing” data. Greg is careful to point out he’s not talking about publishing, per se, but he doesn’t mention what we are talking about.
Second, given we understand our data (which is a reason to categorize it) there are at least three topics to talk about with respect to that data.
1. Why do we care about this data, or perhaps, what is the purpose of the data? The answer to these questions is both critical and essential. They will drive the answer to the next two questions. In my opinion, without an answer to these questions (eventually, if not first or early in our process), discussions about the next two topics will never come to a conclusion. By the way, also my opinion, any answer that somehow embodies a reference to the existing system and service is irrelevant.
2. What are the data collection requirements? This includes who, what, where, why, and how, including storage.
3. What are the publication requirements? Might be zero. Greg suggests above that we could approach the problem of publication in some cases by answering the following question, “Is there any compelling reason not to publish it?” I will object to this. This is never the right question. The right question is always, “Why publish it?” You can’t publish it if you don’t collect it and you don’t collect it if you don’t have a need for it.
All questions must be answered in the positive. Otherwise what’s the point of our discussion? The answer will always default to be collect everything and publish everything, and then let the lawyers fight about what’s public.
Jim
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
If I might offer a comment on this from the data protection perspective...the concept of "sensitive" data is difficult. It appears in the 95 EU Directive, applying to health data, religious data etc....but some data that is in those categories is not sensitive (eg the fact that I got a flu shot, like 49% of Canadians). Other data that is not considered sensitive or is protected (eg the fact that a woman purchases a maternity vitamin at a pharmacy) could be harvested in our world of big data, and cause her employer to cease her employment. So I dislike the term, although the concept of risk in disclosure of data elements is a good one. The next problem one has to face is that end users usually have a very poor perception of the potential risk of data disclosure, so our policies have to reflect that risk from the perspective of the experts here assembled. I understand only a couple of aspects of that risk....data and security and some regulatory issues. I have a really hard time figuring out the data map, how far this stuff is travelling, who is harvesting it, what the secondary value-added service market looks like, who purchases those products.....etc. I depend on you folks in the business to tell us that, or point me to some tutorial that will help be do the research. cheers Stephanie On 2016-12-09 10:50, James Galvin wrote:
On 8 Dec 2016, at 17:28, DANIEL NANGHAKA wrote:
I look at sensitive data as data that exposes a threat to the registrant - this is also contact information.
This is probably too broad a definition. I suspect a case could be made that most if not all data is a potential threat to a registrant because in our world of big data aggregation and correlation are always a threat.
This is a serious problem with data protection law these days, regulatory overreach. While it is true that big data is a significant threat, nobody has come up with a satisfactory solution that I have seen.
I don’t have a suggestion just yet for how to restrict this but it is otherwise a possible starting point for discussions.
Jim
Other records like the NS records may not be sensitive data.
Third parties pick this data and use it for spam. This is the point where I think restricted Access is important. Where there is need for the data the registrant should be asked for consent that the data be shared.
Daniel
Regards Nanghaka Daniel K. Executive Director - ILICIT Africa / Council Member - FOSSFA / Community Lead - ISOC Uganda Chapter Mobile +256 772 898298 (Uganda) Skype: daniel.nanghaka
----------------------------------------- *"Working for Africa" * -----------------------------------------
On Thu, Dec 8, 2016 at 10:11 PM, James Galvin <jgalvin@afilias.info> wrote:
On 7 Dec 2016, at 9:55, Greg Aaron wrote:
In the coming discussions, one approach could be: There are good reasons
to publish the thin data … is there any compelling reason _not_ to publish it? If we can take care of this low-hanging fruit, we will solve part of the puzzle and we can concentrate on the issues around contact data. This is not a proposal to publish thin data only. It’s an attempt to disentangle concepts and find a way forward. Not all data is the same, so let’s stop treating all data the same. We may not have to iterate repeatedly about thin data.
I agree with the principle that we should tease apart “registration data” into a few different categories. The discussion in the rest of this thread has been focused on that and I’ll state I support it. My current view is that there are at least three categories of data: PII (e.g., contact information), operational and explicitly not-PII (e.g., registrar ID and NS records), and other (e.g., registries with specific requirements).
I have two concerns with this discussion though. First, we keep talking about “publishing” data. Greg is careful to point out he’s not talking about publishing, per se, but he doesn’t mention what we are talking about.
Second, given we understand our data (which is a reason to categorize it) there are at least three topics to talk about with respect to that data.
1. Why do we care about this data, or perhaps, what is the purpose of the data? The answer to these questions is both critical and essential. They will drive the answer to the next two questions. In my opinion, without an answer to these questions (eventually, if not first or early in our process), discussions about the next two topics will never come to a conclusion. By the way, also my opinion, any answer that somehow embodies a reference to the existing system and service is irrelevant.
2. What are the data collection requirements? This includes who, what, where, why, and how, including storage.
3. What are the publication requirements? Might be zero. Greg suggests above that we could approach the problem of publication in some cases by answering the following question, “Is there any compelling reason not to publish it?” I will object to this. This is never the right question. The right question is always, “Why publish it?” You can’t publish it if you don’t collect it and you don’t collect it if you don’t have a need for it.
All questions must be answered in the positive. Otherwise what’s the point of our discussion? The answer will always default to be collect everything and publish everything, and then let the lawyers fight about what’s public.
Jim
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
participants (12)
-
Andrew Sullivan -
Carlton Samuels -
DANIEL NANGHAKA -
Gomes, Chuck -
Greg Aaron -
James Galvin -
Lisa Phifer -
Michael D. Palage -
Rob Golding -
Sam Lanfranco -
Stephanie Perrin -
Volker Greimann