For your review - updated RDS Statement of Purpose
Dear All, Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.
All, Please feel free to suggest additional purposes if you think they would be appropriate. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, September 28, 2016 1:12 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Dear All, Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>.
I found (and fixed) two more instances of “gTLD domain names”. Update attached. Scott From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, September 28, 2016 1:12 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Dear All, Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>.
Have read both versions although I didn't see the changes that were made by Scott as I couldn't see the difference as I'm on my phone the structure and intent is correct in what we are delivering. Hope this helps Regards Richard On Wed, Sep 28, 2016, 13:18 Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
I found (and fixed) two more instances of “gTLD domain names”. Update attached.
Scott
*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto: gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Marika Konings *Sent:* Wednesday, September 28, 2016 1:12 PM *To:* gnso-rds-pdp-wg@icann.org *Subject:* [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Dear All,
Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated.
Best regards,
Marika
*Marika Konings*
Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)
Email: marika.konings@icann.org
*Follow the GNSO via Twitter @ICANN_GNSO*
*Find out more about the GNSO by taking our interactive courses <http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>.*
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Richard Padilla MSc
I apologize for missing the last two meetings. I was travelling and had difficulty connecting. I have listened to the call of the 21st, and I am going to listen to the next one as soon as it arrives. I have a number of concerns with the current draft purpose statement, and am consulting my NCSG colleagues on a proposed redraft which I have done. As soon as I hear back from them I will share it with the list, understanding that this is not the same as being on the call. My concerns are basically the following: 1. The purpose of the purpose clause exercise was, as far as I understood it, to come up with a succinct purpose for the exercise in which we are engaged....to limit the exercise to the minimum until such time as we have agreed on policy, as it is generally understood that many policy issues have crept into the WHOIS and RDS without benefit of a full PDP delberation. Our remit is not to assume those policy issues are a fait accompli, it is to examine them, thus the limited scope of the purpose clause. It is a business requirements statement for the exercise. 2. Several implicit assumptions appear to have crept in, namely that an RDS is necessary, and that data will be released through it. We have not got there yet. Discussion of rationales for the RDS is straying way too far, in my view. 3. While a statement of purpose is necessary for the interpretation of ICANN's policies with respect to the collection, use, retention and disclosure of personal information in the context of its registration activities, this is not it. We cannot through this exercise set up a purpose for that, because it requires policy decisions, and we are not there yet. A goal can be compliance with national and regional law, and with internationally recognized human rights obligations, but not crafting the actual purpose statement. I hope that is clear, it is a wee bit convoluted. I will send my proposed redline version as soon as possible. Apologies once again for missing the calls. Stephanie Perrin On 2016-09-28 13:17, Hollenbeck, Scott wrote:
I found (and fixed) two more instances of “gTLD domain names”. Update attached.
Scott
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Marika Konings *Sent:* Wednesday, September 28, 2016 1:12 PM *To:* gnso-rds-pdp-wg@icann.org *Subject:* [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Dear All,
Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated.
Best regards,
Marika
*Marika Konings*
Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)
Email: marika.konings@icann.org <mailto:marika.konings@icann.org>
//
/Follow the GNSO via Twitter @ICANN_GNSO/
/Find out more about the GNSO by taking our interactive courses <http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>./
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
and here is the draft redline version On 2016-09-28 22:34, Stephanie Perrin wrote:
I apologize for missing the last two meetings. I was travelling and had difficulty connecting. I have listened to the call of the 21st, and I am going to listen to the next one as soon as it arrives. I have a number of concerns with the current draft purpose statement, and am consulting my NCSG colleagues on a proposed redraft which I have done. As soon as I hear back from them I will share it with the list, understanding that this is not the same as being on the call. My concerns are basically the following:
1. The purpose of the purpose clause exercise was, as far as I understood it, to come up with a succinct purpose for the exercise in which we are engaged....to limit the exercise to the minimum until such time as we have agreed on policy, as it is generally understood that many policy issues have crept into the WHOIS and RDS without benefit of a full PDP delberation. Our remit is not to assume those policy issues are a fait accompli, it is to examine them, thus the limited scope of the purpose clause. It is a business requirements statement for the exercise.
2. Several implicit assumptions appear to have crept in, namely that an RDS is necessary, and that data will be released through it. We have not got there yet. Discussion of rationales for the RDS is straying way too far, in my view.
3. While a statement of purpose is necessary for the interpretation of ICANN's policies with respect to the collection, use, retention and disclosure of personal information in the context of its registration activities, this is not it. We cannot through this exercise set up a purpose for that, because it requires policy decisions, and we are not there yet. A goal can be compliance with national and regional law, and with internationally recognized human rights obligations, but not crafting the actual purpose statement. I hope that is clear, it is a wee bit convoluted.
I will send my proposed redline version as soon as possible. Apologies once again for missing the calls.
Stephanie Perrin
On 2016-09-28 13:17, Hollenbeck, Scott wrote:
I found (and fixed) two more instances of “gTLD domain names”. Update attached.
Scott
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Marika Konings *Sent:* Wednesday, September 28, 2016 1:12 PM *To:* gnso-rds-pdp-wg@icann.org *Subject:* [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Dear All,
Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated.
Best regards,
Marika
*Marika Konings*
Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)
Email: marika.konings@icann.org <mailto:marika.konings@icann.org>
//
/Follow the GNSO via Twitter @ICANN_GNSO/
/Find out more about the GNSO by taking our interactive courses <http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>./
_______________________________________________ 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
Thanks Stephanie for spending considerable time on this. First I want to say that you are correct that we should not yet assume that a RDS system is needed so the edits you made to fix that seem fine to me. Others are of course welcome to comment on this if they like. Second, it seems to me that we as a WG need to discuss your input on the list before our next WG meeting next Tuesday as well as in that meeting. In that regard I have a couple questions for you: 1. Will you be able to participate in the meeting on 4 October? 2. Can you provide any updates to your redline no later than Monday, 3 October? When you listen to the recording from this week's meeting, you will hear Alan and I both express concerns about dragging our work on a RDS Statement of Purpose out much longer. My personal goal as chair is to try to wrap it up for the most part on next week's call. At the same time I want to make sure that we address the issues you raised. To help us continue to make timely progress, I sincerely hope that you can respond affirmatively to both questions. In the meantime, I encourage everyone to review Stephanie's comments and respond to them on the list. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Wednesday, September 28, 2016 11:44 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose and here is the draft redline version On 2016-09-28 22:34, Stephanie Perrin wrote: I apologize for missing the last two meetings. I was travelling and had difficulty connecting. I have listened to the call of the 21st, and I am going to listen to the next one as soon as it arrives. I have a number of concerns with the current draft purpose statement, and am consulting my NCSG colleagues on a proposed redraft which I have done. As soon as I hear back from them I will share it with the list, understanding that this is not the same as being on the call. My concerns are basically the following: 1. The purpose of the purpose clause exercise was, as far as I understood it, to come up with a succinct purpose for the exercise in which we are engaged....to limit the exercise to the minimum until such time as we have agreed on policy, as it is generally understood that many policy issues have crept into the WHOIS and RDS without benefit of a full PDP delberation. Our remit is not to assume those policy issues are a fait accompli, it is to examine them, thus the limited scope of the purpose clause. It is a business requirements statement for the exercise. 2. Several implicit assumptions appear to have crept in, namely that an RDS is necessary, and that data will be released through it. We have not got there yet. Discussion of rationales for the RDS is straying way too far, in my view. 3. While a statement of purpose is necessary for the interpretation of ICANN's policies with respect to the collection, use, retention and disclosure of personal information in the context of its registration activities, this is not it. We cannot through this exercise set up a purpose for that, because it requires policy decisions, and we are not there yet. A goal can be compliance with national and regional law, and with internationally recognized human rights obligations, but not crafting the actual purpose statement. I hope that is clear, it is a wee bit convoluted. I will send my proposed redline version as soon as possible. Apologies once again for missing the calls. Stephanie Perrin On 2016-09-28 13:17, Hollenbeck, Scott wrote: I found (and fixed) two more instances of "gTLD domain names". Update attached. Scott 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 Marika Konings Sent: Wednesday, September 28, 2016 1:12 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Dear All, Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday's meeting. You are all encouraged to review this version, especially the section 'Specific Purposes for Registration Data and Registration Directory Services', and share your input with the mailing list prior to next week's meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
#1
purpose of gTLD registration data is to provide information
provide seems to be the wrong word, although I'm unsure if store/manage/maintain/record/define are any better
about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle) to enable management of a domain name registration.
I'm struggling with "to enable management of a domain name registration" maybe "enable" should be "assist with" #2
purpose of a system to collect, maintain, and provide access to gTLD Registration Data (hereafter referred to as “the RDS”) is to provide information that is
^ we've already defined it as a systems to "collect, maintain and provide" so the extra "provide" here should probably be "handle" or "manage"
needed by authorized parties to operate a generic top-level domain name in the DNS.
^ RDS isn't needed to operate a domain in the DNS perhaps "to operate a generic top-level domain name in the DNS." should just be "regarding a gTLD" Rob
Thanks Rob for contributing to our discussion. I inserted some questions after Rob's comments to help us discuss them as a group. All - please see and respond to my comments below. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Thursday, September 29, 2016 12:10 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose #1
purpose of gTLD registration data is to provide information
provide seems to be the wrong word, although I'm unsure if store/manage/maintain/record/define are any better [Chuck Gomes] Does anyone, including Rob, have a suggested edit in this regard?
about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle) to enable management of a domain name registration.
I'm struggling with "to enable management of a domain name registration" maybe "enable" should be "assist with" [Chuck Gomes] Does anyone object to this suggested edit or have an alternative one to deal with Rob's concern? #2
purpose of a system to collect, maintain, and provide access to gTLD Registration Data (hereafter referred to as “the RDS”) is to provide information that is
^ we've already defined it as a systems to "collect, maintain and provide" so the extra "provide" here should probably be "handle" or "manage" [Chuck Gomes] Do members support changing 'to provide information'? If so, which option do you prefer: 1) 'to handle information'; 2) 'to manage information'; 3) some other word?
needed by authorized parties to operate a generic top-level domain name in the DNS.
^ RDS isn't needed to operate a domain in the DNS perhaps "to operate a generic top-level domain name in the DNS." should just be "regarding a gTLD" [Chuck Gomes] Does anyone object to this edit or have an alternative suggestion? Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
to "facilitate" the management of a domain name registration throughout its life cycle? Stephanie Perrin On 2016-09-29 10:47, Gomes, Chuck wrote:
Thanks Rob for contributing to our discussion. I inserted some questions after Rob's comments to help us discuss them as a group.
All - please see and respond to my comments below.
Chuck
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Thursday, September 29, 2016 12:10 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
#1
purpose of gTLD registration data is to provide information provide seems to be the wrong word, although I'm unsure if store/manage/maintain/record/define are any better [Chuck Gomes] Does anyone, including Rob, have a suggested edit in this regard?
about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle) to enable management of a domain name registration. I'm struggling with "to enable management of a domain name registration" maybe "enable" should be "assist with" [Chuck Gomes] Does anyone object to this suggested edit or have an alternative one to deal with Rob's concern?
#2
purpose of a system to collect, maintain, and provide access to gTLD Registration Data (hereafter referred to as “the RDS”) is to provide information that is ^ we've already defined it as a systems to "collect, maintain and provide" so the extra "provide" here should probably be "handle" or "manage" [Chuck Gomes] Do members support changing 'to provide information'? If so, which option do you prefer: 1) 'to handle information'; 2) 'to manage information'; 3) some other word?
needed by authorized parties to operate a generic top-level domain name in the DNS. ^ RDS isn't needed to operate a domain in the DNS
perhaps "to operate a generic top-level domain name in the DNS." should just be "regarding a gTLD" [Chuck Gomes] Does anyone object to this edit or have an alternative suggestion?
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
I appreciate the concerns Chuck and others have raised that we are spending too much time on the RDS statement of purpose. I know many of us (myself included) are anxious to get to get to the requirements deliberation phase. That said it’s important that we do a proper job drafting the RDS statement of purpose. As a PDP we’ll be judged on the quality of our work and the statement of purpose will be a very visible output. Rushing through this will not serve us well in the long run With a goal of wrapping this up quickly and efficiently in mind, I’ll skip the intro and goals section and get right to the purpose section. Purpose 1: A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle) to enable management of a domain name registration. I agree that the first part of that statement “…provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle)” is a purpose of RDS. The second part however “to enable management of a domain name registration” does not belong in a purpose statement. This deals with a potential use case which I’m sure we’ll discuss in the requirements deliberation phase. I would suggest an updated purpose 1 read: “A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle).” Purpose 2: A purpose of a system to collect, maintain, and provide access to gTLD registration data (hereafter referred to as “the RDS”) is to provide information that is needed by authorized parties to operate a gTLD generic top-level domain name in the DNS. I have concerns with this second purpose statement. Purpose 2 provides a definition of RDS and one that I don’t feel is accurate. RDS does not collect or maintain gTLD registration data. It does provide access to that data, but as I said on the call the Registration system itself that registries make accessible to registrars via EPP is the system that collects and maintains gTLD registrations data. For purpose 2 how about: “A purpose of RDS is to provide information that is needed by authorized parities to operate a generic top-level domain name in the DNS”. Purpose 3: Further specific purposes of the RDS include: a. To enable contact with registrants, registrars, (registries?), and proxy/privacy service providers associated with gTLD domain names, for specific policy-defined purposes. b. To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions I’m not sure why this is broken into a 3a and 3b. They don’t appear related and should be purpose 3 and 4 respectively. RDS doesn’t include registry data, so only registrants, registrars and proxy/privacy providers apply. The “for specific policy-defined purposes” doesn’t belong in a RDS purpose statement, it’s more appropriate to the requirements deliberation phase. An updated Purpose 3 would read: “A purpose of RDS is to facilitate contact with registrants, registrars and proxy/privacy service providers associated with generic top-level domain names.” For 3b I don’t necessarily agreed with “accurate” in the purpose statement. Having accurate data may be a goal, but the purpose is to display the data of record. In fact a potential use case is to facilitate the correction of inaccurate data. The “under specific and explicit policy-defined conditions” again refers to a potential requirement of RDS but not a purpose. A new purpose 4 would read: “A purpose of RDS is to enable the release of gTLD registration data that may not otherwise be publicly available.” Looking at these 4 purposes I think there is a theme. You could say that they could all be rolled up in the statement “The purpose of RDS is to provide access to information about domain names in a TLD.” As Whois today also provides information about Registrars and Name Servers, perhaps a more fulsome consolidated RDS purpose statement could be: The Purpose of RDS is to provide access to information about Domain Names, Name Servers and Registrars in a TLD. Thank you, Marc Anderson From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, September 28, 2016 1:12 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Dear All, Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>.
Marc, In your last suggestion, are you suggesting that all four purpose statements (1, 2, 3a and 3b) could be replaced with your suggested statement? Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Anderson, Marc Sent: Thursday, September 29, 2016 12:38 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I appreciate the concerns Chuck and others have raised that we are spending too much time on the RDS statement of purpose. I know many of us (myself included) are anxious to get to get to the requirements deliberation phase. That said it’s important that we do a proper job drafting the RDS statement of purpose. As a PDP we’ll be judged on the quality of our work and the statement of purpose will be a very visible output. Rushing through this will not serve us well in the long run With a goal of wrapping this up quickly and efficiently in mind, I’ll skip the intro and goals section and get right to the purpose section. Purpose 1: A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle) to enable management of a domain name registration. I agree that the first part of that statement “…provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle)” is a purpose of RDS. The second part however “to enable management of a domain name registration” does not belong in a purpose statement. This deals with a potential use case which I’m sure we’ll discuss in the requirements deliberation phase. I would suggest an updated purpose 1 read: “A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle).” Purpose 2: A purpose of a system to collect, maintain, and provide access to gTLD registration data (hereafter referred to as “the RDS”) is to provide information that is needed by authorized parties to operate a gTLD generic top-level domain name in the DNS. I have concerns with this second purpose statement. Purpose 2 provides a definition of RDS and one that I don’t feel is accurate. RDS does not collect or maintain gTLD registration data. It does provide access to that data, but as I said on the call the Registration system itself that registries make accessible to registrars via EPP is the system that collects and maintains gTLD registrations data. For purpose 2 how about: “A purpose of RDS is to provide information that is needed by authorized parities to operate a generic top-level domain name in the DNS”. Purpose 3: Further specific purposes of the RDS include: a. To enable contact with registrants, registrars, (registries?), and proxy/privacy service providers associated with gTLD domain names, for specific policy-defined purposes. b. To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions I’m not sure why this is broken into a 3a and 3b. They don’t appear related and should be purpose 3 and 4 respectively. RDS doesn’t include registry data, so only registrants, registrars and proxy/privacy providers apply. The “for specific policy-defined purposes” doesn’t belong in a RDS purpose statement, it’s more appropriate to the requirements deliberation phase. An updated Purpose 3 would read: “A purpose of RDS is to facilitate contact with registrants, registrars and proxy/privacy service providers associated with generic top-level domain names.” For 3b I don’t necessarily agreed with “accurate” in the purpose statement. Having accurate data may be a goal, but the purpose is to display the data of record. In fact a potential use case is to facilitate the correction of inaccurate data. The “under specific and explicit policy-defined conditions” again refers to a potential requirement of RDS but not a purpose. A new purpose 4 would read: “A purpose of RDS is to enable the release of gTLD registration data that may not otherwise be publicly available.” Looking at these 4 purposes I think there is a theme. You could say that they could all be rolled up in the statement “The purpose of RDS is to provide access to information about domain names in a TLD.” As Whois today also provides information about Registrars and Name Servers, perhaps a more fulsome consolidated RDS purpose statement could be: The Purpose of RDS is to provide access to information about Domain Names, Name Servers and Registrars in a TLD. Thank you, Marc Anderson 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 Marika Konings Sent: Wednesday, September 28, 2016 1:12 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Dear All, Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>.
I would suggest that if you boil it down to this, you need to say " The Purpose of RDS is to */manage/* access to information about Domain Names, Name Servers and Registrars in a TLD. (I would also be tempted to add "in accordance with policy and relevant law" but I realize we need to limit the hobby horses we let into this corral) I appreciate this effort to condense the thing. Stephanie On 2016-10-04 09:40, Gomes, Chuck wrote:
Marc,
In your last suggestion, are you suggesting that all four purpose statements (1, 2, 3a and 3b) could be replaced with your suggested statement?
Chuck
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Anderson, Marc *Sent:* Thursday, September 29, 2016 12:38 PM *To:* gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I appreciate the concerns Chuck and others have raised that we are spending too much time on the RDS statement of purpose. I know many of us (myself included) are anxious to get to get to the requirements deliberation phase. That said it’s important that we do a proper job drafting the RDS statement of purpose. As a PDP we’ll be judged on the quality of our work and the statement of purpose will be a very visible output. Rushing through this will not serve us well in the long run
With a goal of wrapping this up quickly and efficiently in mind, I’ll skip the intro and goals section and get right to the purpose section.
Purpose 1: A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle) to enable management of a domain name registration.
I agree that the first part of that statement “…provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle)” is a purpose of RDS. The second part however “to enable management of a domain name registration” does not belong in a purpose statement. This deals with a potential use case which I’m sure we’ll discuss in the requirements deliberation phase. I would suggest an updated purpose 1 read: “A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle).”
Purpose 2: A purpose of a system to collect, maintain, and provide access to gTLD registration data (hereafter referred to as “the RDS”) is to provide information that is needed by authorized parties to operate a gTLD generic top-level domain name in the DNS.
I have concerns with this second purpose statement. Purpose 2 provides a definition of RDS and one that I don’t feel is accurate. RDS does not collect or maintain gTLD registration data. It does provide access to that data, but as I said on the call the Registration system itself that registries make accessible to registrars via EPP is the system that collects and maintains gTLD registrations data. For purpose 2 how about: “A purpose of RDS is to provide information that is needed by authorized parities to operate a generic top-level domain name in the DNS”.
Purpose 3: Further specific purposes of the RDS include:
a.To enable contact with registrants, registrars, (registries?), and proxy/privacy service providers associated with gTLD domain names, for specific policy-defined purposes.
b.To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions
I’m not sure why this is broken into a 3a and 3b. They don’t appear related and should be purpose 3 and 4 respectively. RDS doesn’t include registry data, so only registrants, registrars and proxy/privacy providers apply. The “for specific policy-defined purposes” doesn’t belong in a RDS purpose statement, it’s more appropriate to the requirements deliberation phase. An updated Purpose 3 would read: “A purpose of RDS is to facilitate contact with registrants, registrars and proxy/privacy service providers associated with generic top-level domain names.”
For 3b I don’t necessarily agreed with “accurate” in the purpose statement. Having accurate data may be a goal, but the purpose is to display the data of record. In fact a potential use case is to facilitate the correction of inaccurate data. The “under specific and explicit policy-defined conditions” again refers to a potential requirement of RDS but not a purpose. A new purpose 4 would read: “A purpose of RDS is to enable the release of gTLD registration data that may not otherwise be publicly available.”
Looking at these 4 purposes I think there is a theme. You could say that they could all be rolled up in the statement “The purpose of RDS is to provide access to information about domain names in a TLD.” As Whois today also provides information about Registrars and Name Servers, perhaps a more fulsome consolidated RDS purpose statement could be:
The Purpose of RDS is to provide access to information about Domain Names, Name Servers and Registrars in a TLD.
Thank you,
Marc Anderson
*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 *Marika Konings *Sent:* Wednesday, September 28, 2016 1:12 PM *To:* gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:* [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Dear All,
Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated.
Best regards,
Marika
*Marika Konings*
Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)
Email: marika.konings@icann.org <mailto:marika.konings@icann.org>
//
/Follow the GNSO via Twitter @ICANN_GNSO/
/Find out more about the GNSO by taking our interactive courses <http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>./
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
+1 to Stephanie. Leaving it as "to provide access" may create an expectation that cannot (or should not) be met. Am 04.10.2016 um 15:53 schrieb Stephanie Perrin:
I would suggest that if you boil it down to this, you need to say " The Purpose of RDS is to */manage/* access to information about Domain Names, Name Servers and Registrars in a TLD. (I would also be tempted to add "in accordance with policy and relevant law" but I realize we need to limit the hobby horses we let into this corral)
I appreciate this effort to condense the thing.
Stephanie
On 2016-10-04 09:40, Gomes, Chuck wrote:
Marc,
In your last suggestion, are you suggesting that all four purpose statements (1, 2, 3a and 3b) could be replaced with your suggested statement?
Chuck
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Anderson, Marc *Sent:* Thursday, September 29, 2016 12:38 PM *To:* gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I appreciate the concerns Chuck and others have raised that we are spending too much time on the RDS statement of purpose. I know many of us (myself included) are anxious to get to get to the requirements deliberation phase. That said it’s important that we do a proper job drafting the RDS statement of purpose. As a PDP we’ll be judged on the quality of our work and the statement of purpose will be a very visible output. Rushing through this will not serve us well in the long run
With a goal of wrapping this up quickly and efficiently in mind, I’ll skip the intro and goals section and get right to the purpose section.
Purpose 1: A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle) to enable management of a domain name registration.
I agree that the first part of that statement “…provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle)” is a purpose of RDS. The second part however “to enable management of a domain name registration” does not belong in a purpose statement. This deals with a potential use case which I’m sure we’ll discuss in the requirements deliberation phase. I would suggest an updated purpose 1 read: “A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle).”
Purpose 2: A purpose of a system to collect, maintain, and provide access to gTLD registration data (hereafter referred to as “the RDS”) is to provide information that is needed by authorized parties to operate a gTLD generic top-level domain name in the DNS.
I have concerns with this second purpose statement. Purpose 2 provides a definition of RDS and one that I don’t feel is accurate. RDS does not collect or maintain gTLD registration data. It does provide access to that data, but as I said on the call the Registration system itself that registries make accessible to registrars via EPP is the system that collects and maintains gTLD registrations data. For purpose 2 how about: “A purpose of RDS is to provide information that is needed by authorized parities to operate a generic top-level domain name in the DNS”.
Purpose 3: Further specific purposes of the RDS include:
a.To enable contact with registrants, registrars, (registries?), and proxy/privacy service providers associated with gTLD domain names, for specific policy-defined purposes.
b.To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions
I’m not sure why this is broken into a 3a and 3b. They don’t appear related and should be purpose 3 and 4 respectively. RDS doesn’t include registry data, so only registrants, registrars and proxy/privacy providers apply. The “for specific policy-defined purposes” doesn’t belong in a RDS purpose statement, it’s more appropriate to the requirements deliberation phase. An updated Purpose 3 would read: “A purpose of RDS is to facilitate contact with registrants, registrars and proxy/privacy service providers associated with generic top-level domain names.”
For 3b I don’t necessarily agreed with “accurate” in the purpose statement. Having accurate data may be a goal, but the purpose is to display the data of record. In fact a potential use case is to facilitate the correction of inaccurate data. The “under specific and explicit policy-defined conditions” again refers to a potential requirement of RDS but not a purpose. A new purpose 4 would read: “A purpose of RDS is to enable the release of gTLD registration data that may not otherwise be publicly available.”
Looking at these 4 purposes I think there is a theme. You could say that they could all be rolled up in the statement “The purpose of RDS is to provide access to information about domain names in a TLD.” As Whois today also provides information about Registrars and Name Servers, perhaps a more fulsome consolidated RDS purpose statement could be:
The Purpose of RDS is to provide access to information about Domain Names, Name Servers and Registrars in a TLD.
Thank you,
Marc Anderson
*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 *Marika Konings *Sent:* Wednesday, September 28, 2016 1:12 PM *To:* gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:* [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Dear All,
Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated.
Best regards,
Marika
*Marika Konings*
Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)
Email: marika.konings@icann.org <mailto:marika.konings@icann.org>
//
/Follow the GNSO via Twitter @ICANN_GNSO/
/Find out more about the GNSO by taking our interactive courses <http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>./
_______________________________________________ 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.
Purpose 1: This is more a statement of what Registration Data is, so probably shouldn't be a "numbered purpose", and perhaps should only be included, if we also include definitions of Registry, Registrar, Nameserver etc ? Or simplified to: THE purpose of "gTLD Registration Data" is to record information necessary for the lifecycle of a domain name (as specified by ICANN's Diagram of gTLD Lifecycle). Purpose 2: I see Andrew has picked up on defining the "collect" concept - Volker may be correct in function but RDS doesn't "collect" in the normal use of the word, it may "collate" though. Perhaps this should be simplified to: THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars] Purpose 3(a/b) are possible use cases, not Purposes as such "Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Rob
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org] On Behalf Of Rob Golding Sent: Tuesday, October 04, 2016 10:42 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Purpose 1:
This is more a statement of what Registration Data is, so probably shouldn't be a "numbered purpose", and perhaps should only be included, if we also include definitions of Registry, Registrar, Nameserver etc ? Or simplified to:
THE purpose of "gTLD Registration Data" is to record information necessary for the lifecycle of a domain name (as specified by ICANN's Diagram of gTLD Lifecycle).
I like where you're going with this, but data doesn't record information. If this is intended to be a definition, and not a statement of purpose, this might work better: "gTLD Registration Data" is information associated with the lifecycle of a domain name (as specified by ICANN's Diagram of gTLD Lifecycle).
Purpose 2:
I see Andrew has picked up on defining the "collect" concept - Volker may be correct in function but RDS doesn't "collect" in the normal use of the word, it may "collate" though.
Perhaps this should be simplified to:
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate.
Agreed, with one minor suggestion: "access to information about generic top-level domain registries, registrars, names, and name servers." Scott
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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.
Agreed Volker, That is a better focus of energy right there. Theo Volker Greimann schreef op 2016-10-05 01:58 PM:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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
Agreed Volker -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 5 Oct 2016, at 13:58, Volker Greimann <vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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
As some in the WG have reminded us, we're not to take current policies for granted. To build the edifice and arrive at policy statements for the future, we must lay a good foundation and should not omit the obvious. So just because accuracy is in current ICANN policy is no reason to exclude it from the Statement of Purpose. Accuracy is required in order to deliver other things in the Statement of Purpose, like "provid[ing] information about the lifecycle of a domain name ...to enable management of a domain name registration." We are talking about a variety of registration data, including what domains were registered, their registration dates, what nameservers they are associated with, and so on. Delivering inaccurate information in these areas will render an RDS pointless. The accuracy of contact data specifically has long been a topic at ICANN. I think that having perfect, 100%-all-the-time accurate contact data is a practical impossibility. While 100% accuracy of contact data is not possible, it is valid to have accuracy as a general goal. Our WG Charter say that in Phase 1, the WG should discuss "What steps should be taken to improve data accuracy?" That implies that accuracy is a general requirement or goal. Perhaps a discussion of the degree of contact data accuracy will come at some point. See also SSAC 055. So for these reasons I suggest that accuracy be left in. All best, --Greg -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of benny@nordreg.se Sent: Wednesday, October 5, 2016 8:10 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Agreed Volker -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 5 Oct 2016, at 13:58, Volker Greimann <vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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
I agree with Greg. We must remember that a large number of the users of ‘Whois’ don’t have the detailed knowledge of how the registries operate. They will just see it for what it is when they do a look up. We must strive for 100% accuracy, i know this may be impossible to achieve but it should be what we aim for. If we don’t, how do we bench mark accuracy - were happy with only 80% or 50% accuracy? Is this really what we want - all this hard work to have a RDS that is more likely to be inaccurate than accurate? Cheers Dick Richard Leaning External Relations RIPE NCC
On 6 Oct 2016, at 11:44, Greg Aaron <gca@icginc.com> wrote:
As some in the WG have reminded us, we're not to take current policies for granted. To build the edifice and arrive at policy statements for the future, we must lay a good foundation and should not omit the obvious. So just because accuracy is in current ICANN policy is no reason to exclude it from the Statement of Purpose.
Accuracy is required in order to deliver other things in the Statement of Purpose, like "provid[ing] information about the lifecycle of a domain name ...to enable management of a domain name registration." We are talking about a variety of registration data, including what domains were registered, their registration dates, what nameservers they are associated with, and so on. Delivering inaccurate information in these areas will render an RDS pointless.
The accuracy of contact data specifically has long been a topic at ICANN. I think that having perfect, 100%-all-the-time accurate contact data is a practical impossibility. While 100% accuracy of contact data is not possible, it is valid to have accuracy as a general goal.
Our WG Charter say that in Phase 1, the WG should discuss "What steps should be taken to improve data accuracy?" That implies that accuracy is a general requirement or goal. Perhaps a discussion of the degree of contact data accuracy will come at some point. See also SSAC 055.
So for these reasons I suggest that accuracy be left in.
All best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of benny@nordreg.se Sent: Wednesday, October 5, 2016 8:10 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Agreed Volker -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 5 Oct 2016, at 13:58, Volker Greimann <vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
+1 -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Richard Leaning Sent: Thursday, October 6, 2016 7:16 AM To: Greg Aaron <gca@icginc.com> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I agree with Greg. We must remember that a large number of the users of ‘Whois’ don’t have the detailed knowledge of how the registries operate. They will just see it for what it is when they do a look up. We must strive for 100% accuracy, i know this may be impossible to achieve but it should be what we aim for. If we don’t, how do we bench mark accuracy - were happy with only 80% or 50% accuracy? Is this really what we want - all this hard work to have a RDS that is more likely to be inaccurate than accurate? Cheers Dick Richard Leaning External Relations RIPE NCC
On 6 Oct 2016, at 11:44, Greg Aaron <gca@icginc.com> wrote:
As some in the WG have reminded us, we're not to take current policies for granted. To build the edifice and arrive at policy statements for the future, we must lay a good foundation and should not omit the obvious. So just because accuracy is in current ICANN policy is no reason to exclude it from the Statement of Purpose.
Accuracy is required in order to deliver other things in the Statement of Purpose, like "provid[ing] information about the lifecycle of a domain name ...to enable management of a domain name registration." We are talking about a variety of registration data, including what domains were registered, their registration dates, what nameservers they are associated with, and so on. Delivering inaccurate information in these areas will render an RDS pointless.
The accuracy of contact data specifically has long been a topic at ICANN. I think that having perfect, 100%-all-the-time accurate contact data is a practical impossibility. While 100% accuracy of contact data is not possible, it is valid to have accuracy as a general goal.
Our WG Charter say that in Phase 1, the WG should discuss "What steps should be taken to improve data accuracy?" That implies that accuracy is a general requirement or goal. Perhaps a discussion of the degree of contact data accuracy will come at some point. See also SSAC 055.
So for these reasons I suggest that accuracy be left in.
All best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of benny@nordreg.se Sent: Wednesday, October 5, 2016 8:10 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Agreed Volker -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 5 Oct 2016, at 13:58, Volker Greimann <vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Greg,
Our WG Charter say that in Phase 1, the WG should discuss "What steps should be taken to improve data accuracy?" That implies that accuracy is a general requirement or goal. I disagree. It asks a question that must be answered by our group, but it does not presume any result. If we come down to answer this question that no improvement is reasonably possible, then that would also fulfill this charter question.
Best, Volker
So for these reasons I suggest that accuracy be left in.
All best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of benny@nordreg.se Sent: Wednesday, October 5, 2016 8:10 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Agreed Volker -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 5 Oct 2016, at 13:58, Volker Greimann <vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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
-- 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.
It seems to me in reading through this thread that there are a couple of different but interrelated points being made. A number of people have pointed out that Data Accuracy is within the scope of this working group. I think that is clearly the case and I don’t think that anyone is actually disagreeing with that point. Others have pointed out that accurate data should be a goal. I think that is something we can all agree on, accurate data is better than inaccurate data. What I'm sure will be debated though is the lengths and measures required towards that goal. The other point being discussed is if it is "a purpose" of RDS to be accurate. Here I think the definition of RDS is important. If we are talking about the entire Registration Data ecosystem if you will, then accuracy would seem to be in play. If we are talking about purpose of the system that displays Registration Data, then I'm not sure it is. The existing Whois RDS doesn't do anything to ensure accurate data, it simply displays the data of record, accurate or not. Specification 2 of the 2013 RAA is the "Whois accuracy program specification". A purpose of that specification is to ensure accurate Whois data. I don't think a purpose of the Registration Directory Service is accuracy; the purpose of that system is simply to display Registration Data. Thank you, Marc -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Thursday, October 06, 2016 6:45 AM To: benny@nordreg.se; Volker Greimann Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose As some in the WG have reminded us, we're not to take current policies for granted. To build the edifice and arrive at policy statements for the future, we must lay a good foundation and should not omit the obvious. So just because accuracy is in current ICANN policy is no reason to exclude it from the Statement of Purpose. Accuracy is required in order to deliver other things in the Statement of Purpose, like "provid[ing] information about the lifecycle of a domain name ...to enable management of a domain name registration." We are talking about a variety of registration data, including what domains were registered, their registration dates, what nameservers they are associated with, and so on. Delivering inaccurate information in these areas will render an RDS pointless. The accuracy of contact data specifically has long been a topic at ICANN. I think that having perfect, 100%-all-the-time accurate contact data is a practical impossibility. While 100% accuracy of contact data is not possible, it is valid to have accuracy as a general goal. Our WG Charter say that in Phase 1, the WG should discuss "What steps should be taken to improve data accuracy?" That implies that accuracy is a general requirement or goal. Perhaps a discussion of the degree of contact data accuracy will come at some point. See also SSAC 055. So for these reasons I suggest that accuracy be left in. All best, --Greg -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of benny@nordreg.se Sent: Wednesday, October 5, 2016 8:10 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Agreed Volker -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 5 Oct 2016, at 13:58, Volker Greimann <vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
The purpose of the PDP is to make policy about more than just the output mechanism. A Phase 1 mandate in the Charter is to consider: "What are the fundamental requirements for gTLD registration data? When addressing this question, the PDP WG should consider, at a minimum, users and purposes and associated access, accuracy, data element, and privacy requirements." -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Anderson, Marc Sent: Thursday, October 6, 2016 10:33 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose It seems to me in reading through this thread that there are a couple of different but interrelated points being made. A number of people have pointed out that Data Accuracy is within the scope of this working group. I think that is clearly the case and I don’t think that anyone is actually disagreeing with that point. Others have pointed out that accurate data should be a goal. I think that is something we can all agree on, accurate data is better than inaccurate data. What I'm sure will be debated though is the lengths and measures required towards that goal. The other point being discussed is if it is "a purpose" of RDS to be accurate. Here I think the definition of RDS is important. If we are talking about the entire Registration Data ecosystem if you will, then accuracy would seem to be in play. If we are talking about purpose of the system that displays Registration Data, then I'm not sure it is. The existing Whois RDS doesn't do anything to ensure accurate data, it simply displays the data of record, accurate or not. Specification 2 of the 2013 RAA is the "Whois accuracy program specification". A purpose of that specification is to ensure accurate Whois data. I don't think a purpose of the Registration Directory Service is accuracy; the purpose of that system is simply to display Registration Data. Thank you, Marc -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Thursday, October 06, 2016 6:45 AM To: benny@nordreg.se; Volker Greimann Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose As some in the WG have reminded us, we're not to take current policies for granted. To build the edifice and arrive at policy statements for the future, we must lay a good foundation and should not omit the obvious. So just because accuracy is in current ICANN policy is no reason to exclude it from the Statement of Purpose. Accuracy is required in order to deliver other things in the Statement of Purpose, like "provid[ing] information about the lifecycle of a domain name ...to enable management of a domain name registration." We are talking about a variety of registration data, including what domains were registered, their registration dates, what nameservers they are associated with, and so on. Delivering inaccurate information in these areas will render an RDS pointless. The accuracy of contact data specifically has long been a topic at ICANN. I think that having perfect, 100%-all-the-time accurate contact data is a practical impossibility. While 100% accuracy of contact data is not possible, it is valid to have accuracy as a general goal. Our WG Charter say that in Phase 1, the WG should discuss "What steps should be taken to improve data accuracy?" That implies that accuracy is a general requirement or goal. Perhaps a discussion of the degree of contact data accuracy will come at some point. See also SSAC 055. So for these reasons I suggest that accuracy be left in. All best, --Greg -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of benny@nordreg.se Sent: Wednesday, October 5, 2016 8:10 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Agreed Volker -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 5 Oct 2016, at 13:58, Volker Greimann <vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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 _______________________________________________ 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
Well said, Marc! You put into order what I tried to express. Best, Volker Am 06.10.2016 um 16:33 schrieb Anderson, Marc:
It seems to me in reading through this thread that there are a couple of different but interrelated points being made.
A number of people have pointed out that Data Accuracy is within the scope of this working group. I think that is clearly the case and I don’t think that anyone is actually disagreeing with that point.
Others have pointed out that accurate data should be a goal. I think that is something we can all agree on, accurate data is better than inaccurate data. What I'm sure will be debated though is the lengths and measures required towards that goal.
The other point being discussed is if it is "a purpose" of RDS to be accurate. Here I think the definition of RDS is important. If we are talking about the entire Registration Data ecosystem if you will, then accuracy would seem to be in play. If we are talking about purpose of the system that displays Registration Data, then I'm not sure it is. The existing Whois RDS doesn't do anything to ensure accurate data, it simply displays the data of record, accurate or not.
Specification 2 of the 2013 RAA is the "Whois accuracy program specification". A purpose of that specification is to ensure accurate Whois data. I don't think a purpose of the Registration Directory Service is accuracy; the purpose of that system is simply to display Registration Data.
Thank you, Marc
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Thursday, October 06, 2016 6:45 AM To: benny@nordreg.se; Volker Greimann Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
As some in the WG have reminded us, we're not to take current policies for granted. To build the edifice and arrive at policy statements for the future, we must lay a good foundation and should not omit the obvious. So just because accuracy is in current ICANN policy is no reason to exclude it from the Statement of Purpose.
Accuracy is required in order to deliver other things in the Statement of Purpose, like "provid[ing] information about the lifecycle of a domain name ...to enable management of a domain name registration." We are talking about a variety of registration data, including what domains were registered, their registration dates, what nameservers they are associated with, and so on. Delivering inaccurate information in these areas will render an RDS pointless.
The accuracy of contact data specifically has long been a topic at ICANN. I think that having perfect, 100%-all-the-time accurate contact data is a practical impossibility. While 100% accuracy of contact data is not possible, it is valid to have accuracy as a general goal.
Our WG Charter say that in Phase 1, the WG should discuss "What steps should be taken to improve data accuracy?" That implies that accuracy is a general requirement or goal. Perhaps a discussion of the degree of contact data accuracy will come at some point. See also SSAC 055.
So for these reasons I suggest that accuracy be left in.
All best, --Greg
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of benny@nordreg.se Sent: Wednesday, October 5, 2016 8:10 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Agreed Volker -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 5 Oct 2016, at 13:58, Volker Greimann <vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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 _______________________________________________ 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.
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > 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
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) • Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- 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<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200 From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org>, Volker Greimann <vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) • Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- 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<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
-- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200
From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org>, Volker Greimann <vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw <https://community.icann.org/x/E4xlAw>) includes the following question:
As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……)
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Rod, By that statement are you suggesting that the RDS will potentially reject data updates from the registrar/registry ? I would conclude that is a dangerous road to go down if you are. I am not suggesting you are, just wanting to confirm :) Kind regards, Chris From: "Rod Rasmussen" <rrasmussen@infoblox.com> To: "benny" <benny@nordreg.se> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 5 October, 2016 20:37:11 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200 From: < gnso-rds-pdp-wg-bounces@icann.org > on behalf of "Metalitz, Steven" < met@msk.com > Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' < marika.konings@icann.org >, Volker Greimann < vgreimann@key-systems.net >, " gnso-rds-pdp-wg@icann.org " < gnso-rds-pdp-wg@icann.org > Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “ data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz From: gnso-rds-pdp-wg-bounces@icann.org [ mailto:gnso-rds-pdp-wg-bounces@icann.org ] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw ) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum , the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, " gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann " < gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net > wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > 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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Chris, The registrar would in that case be acting in the role of a validator, and follow the proper protocol which would include the required authorizations (which may vary depending on the security settings specified by the contact holder in question) to make the requested changes. There is certainly a use-case where a malicious registrar or their reseller (there have been many) could have their proposed “change” rejected as an anti-fraud measure, but that would be because they also didn’t have the required change authorization details needed for the request in the first place. That is a feature, not a bug, as it protects registrants’ and others rights. This is way in the implementation weeds though - probably not a level we’d need to be concerned about here. Rod
On Oct 5, 2016, at 1:55 PM, Chris Pelling <chris@netearth.net> wrote:
Hi Rod,
By that statement are you suggesting that the RDS will potentially reject data updates from the registrar/registry ? I would conclude that is a dangerous road to go down if you are. I am not suggesting you are, just wanting to confirm :)
Kind regards,
Chris
From: "Rod Rasmussen" <rrasmussen@infoblox.com> To: "benny" <benny@nordreg.se> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 5 October, 2016 20:37:11 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
-- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200
From: <gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
From: gnso-rds-pdp-wg-bounces@icann.org <mailto: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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw <https://community.icann.org/x/E4xlAw>) includes the following question:
As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……)
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Rod, this would be a new role for registrars then that is not yet a contractual requirement. Before unloading this dump truck at the doorstep of contracted parties, please consider the operational and financial impact such a proposal would have. I very strongly suggest that we keep the responsibility for data accuracy where it currently rests: with the registered name holder. Best, Volker Am 05.10.2016 um 23:35 schrieb Rod Rasmussen:
Chris,
The registrar would in that case be acting in the role of a validator, and follow the proper protocol which would include the required authorizations (which may vary depending on the security settings specified by the contact holder in question) to make the requested changes. There is certainly a use-case where a malicious registrar or their reseller (there have been many) could have their proposed “change” rejected as an anti-fraud measure, but that would be because they also didn’t have the required change authorization details needed for the request in the first place. That is a feature, not a bug, as it protects registrants’ and others rights. This is way in the implementation weeds though - probably not a level we’d need to be concerned about here.
Rod
On Oct 5, 2016, at 1:55 PM, Chris Pelling <chris@netearth.net <mailto:chris@netearth.net>> wrote:
Hi Rod,
By that statement are you suggesting that the RDS will potentially reject data updates from the registrar/registry ? I would conclude that is a dangerous road to go down if you are. I am not suggesting you are, just wanting to confirm :)
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Rod Rasmussen" <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> *To: *"benny" <benny@nordreg.se <mailto:benny@nordreg.se>> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Wednesday, 5 October, 2016 20:37:11 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200 *From:*<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> *Date:*Wednesday, 5 October 2016 at 19:32 *To:*'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz *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*Marika Konings *Sent:*Wednesday, October 05, 2016 12:53 PM *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (seehttps://community.icann.org/x/E4xlAw) includes the following question: ** */AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach consensusrecommendations byconsidering,*ataminimum*, thefollowingcomplexandinter-related questions:/ /(…..)/ ·*/Data Accuracy:/**//*/Whatstepsshould betakentoimprovedataaccuracy?/ /(……)/ Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list >gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> >https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- 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 <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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.
Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
-- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200
From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org>, Volker Greimann <vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question:
As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……)
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > 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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Thank you very much Holly for the reminder of our charter tasks. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Holly Raiche Sent: Wednesday, October 05, 2016 8:38 PM To: Rod Rasmussen <rrasmussen@infoblox.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: • Users/Purposes: Who should have access to gTLD registration data and why? • Gated Access: What steps should be taken to control data access for each user/purpose? • Data Accuracy: What steps should be taken to improve data accuracy? • Data Elements: What data should be collected, stored, and disclosed? • Privacy: What steps are needed to protect data and privacy? • Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? •Compliance: What steps are needed to enforce these policies? • System Model:What system requirements must be satisfied by any next-generation RDS implementation? • Cost: What costs will be incurred and how must they be covered? • Benefits: What benefits will be achieved and how will they be measured? • Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com<mailto:rrasmussen@infoblox.com>> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, benny@nordreg.se<mailto:benny@nordreg.se> wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200 From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com<mailto:met@msk.com>> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org<mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz 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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) • Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- 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<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
+1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
*On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PD**P to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy*
Later - what The Charter tasked this Working Group with:
*As part of its Phase 1 deliberations, **the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:* * Users/Purposes: **Who should have access to gTLD registration data and why?* * Gated Access: **What steps should be taken to control data access for each user/purpose?* * Data Accuracy: **What steps should be taken to improve data accuracy?* * Data Elements: **What data should be collected, stored, and disclosed?* * Privacy: **What steps are needed to protect data and privacy?* * Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?* *Compliance: What steps are needed to enforce these policies?* * System Model:What system requirements must be satisfied by any next-generation RDS implementation?* * Cost: What costs will be incurred and how must they be covered?* * Benefits: What benefits will be achieved and how will they be measured?* * Risks: What risks do stakeholders face and how will they be reconciled?*
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
-- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200
*From: *<gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> *Date: *Wednesday, 5 October 2016 at 19:32 *To: *'Marika Konings' <marika.konings@icann.org>, Volker Greimann < vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" < gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org <gnso-rds-pdp-wg-bounces@icann.org>] *On Behalf Of *Marika Konings *Sent:* Wednesday, October 05, 2016 12:53 PM *To:* Volker Greimann; gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann. org/x/E4xlAw) includes the following question:
*As part of its Phase 1 deliberations, **the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:* *(…..)* · *Data Accuracy:* *What steps should be taken to improve data accuracy?* *(……)*
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > 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 <http://www.rrpproxy.net/> www.domaindiscount24.com / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems 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 <http://www.rrpproxy.net/> www.domaindiscount24.com / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems 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
_______________________________________________ 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
I agree with Greg Aaron, Rod, Dick and others that dealing with accuracy is very much in our scope. Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Moving to a different attack vector on data accuracy, our scope doesn't just include the output method or the end product. We are dealing, if you will, with the life cycle of the data. Holly's helpful reminder of our charter makes that clear, and wishing otherwise won't make it so. Greg On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== *Carlton A Samuels*
*Mobile: 876-818-1799 <876-818-1799>Strategy, Planning, Governance, Assessment & Turnaround* =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
*On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PD**P to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy*
Later - what The Charter tasked this Working Group with:
*As part of its Phase 1 deliberations, **the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:* * Users/Purposes: **Who should have access to gTLD registration data and why?* * Gated Access: **What steps should be taken to control data access for each user/purpose?* * Data Accuracy: **What steps should be taken to improve data accuracy?* * Data Elements: **What data should be collected, stored, and disclosed?* * Privacy: **What steps are needed to protect data and privacy?* * Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?* *Compliance: What steps are needed to enforce these policies?* * System Model:What system requirements must be satisfied by any next-generation RDS implementation?* * Cost: What costs will be incurred and how must they be covered?* * Benefits: What benefits will be achieved and how will they be measured?* * Risks: What risks do stakeholders face and how will they be reconciled?*
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
-- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200
*From: *<gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> *Date: *Wednesday, 5 October 2016 at 19:32 *To: *'Marika Konings' <marika.konings@icann.org>, Volker Greimann < vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" < gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounce s@icann.org <gnso-rds-pdp-wg-bounces@icann.org>] *On Behalf Of *Marika Konings *Sent:* Wednesday, October 05, 2016 12:53 PM *To:* Volker Greimann; gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question:
*As part of its Phase 1 deliberations, **the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:* *(…..)* · *Data Accuracy:* *What steps should be taken to improve data accuracy?* *(……)*
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > 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 <http://www.rrpproxy.net/> www.domaindiscount24.com / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems 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 <http://www.rrpproxy.net/> www.domaindiscount24.com / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems 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
_______________________________________________ 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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Greg, > Arguments to the contrary tend to look like a Defense of Bad Data. I > can't think of any reasons to defend bad data, unless one wants a bad > database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare > It's reasonable to strive for perfectly accurate data, but accept that > one will never get there. There should be commercially reasonable and > proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. > We have not (in this group) discussed data migration, but assuming a > Garbage In, Garbage Out approach doesn't seem reasonable. Whether all > the data is validated before migration, or just validated as part of a > normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker > > On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels > <carlton.samuels@gmail.com <mailto:carlton.samuels@gmail.com>> wrote: > > +1. > > Not to make too fine a point of it. But the EWG was tasked to > re-imagine an RDS. If this PDP is tasked to build on the works of > EWG maybe it'd be useful to re-visit certain ideas we now hold as > verities. > > -Carlton > > > ============================== > /Carlton A Samuels/ > /Mobile: 876-818-1799 <tel:876-818-1799> > Strategy, Planning, Governance, Assessment & Turnaround/ > ============================= > > On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche > <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote: > > Folks > > Maybe we need to back up a bit and go back to the Charter and > what we are supposed to be doing. Let me quote directly from it: > > First - background: Quoting the Charter on the Board decision > to launch this PDP: > / > / > /On 26 May, 2015, the ICANN Board passed a resolution adopting > that Process Framework and reaffirming its 2012 request for a > Board - initiated PD//P to define the purpose of collecting, > maintaining and providing access to gTLD registration > data, and to consider safeguards for protecting data, using > the recommendations in the EWG’s Final Report as an input to, > and, if appropriate, as the foundation for a new gTLD policy/ > > Later - what The Charter tasked this Working Group with: > > /As part of its Phase 1 deliberations, //the PDP WG should > work to reach consensus recommendations by considering, at a > minimum, the following complex and inter-related questions:/ > / Users/Purposes: //Who should have access to gTLD > registration data and why?/ > / Gated Access: //What steps should be taken to control data > access for each user/purpose?/ > / Data Accuracy: //What steps should be taken to improve data > accuracy?/ > / Data Elements: //What data should be collected, stored, and > disclosed?/ > / Privacy: //What steps are needed to protect data and privacy?/ > / Coexistence: What steps should be taken to enable > next-generation RDS coexistence with and replacement of the > legacy WHOIS system?/ > /Compliance: What steps are needed to enforce these policies?/ > / System Model:What system requirements must be satisfied by > any next-generation RDS implementation?/ > / Cost: What costs will be incurred and how must they be > covered?/ > / Benefits: What benefits will be achieved and how will they > be measured?/ > / Risks: What risks do stakeholders face and how will they be > reconciled?/ > > So accuracy’s there - along with a lot of other issues. That > is not saying that accuracy is not covered in existing > requirements on registries/registrars. But it is giving a > broader meaning to RDS - i.e., it’s not just about collection, > maintenance and access to data; it’s also about safeguards, > etc - using the EWG work. > > So thanks Rob. It’s a bit premature to rule issues out when > they are well and truly on our table. > > Holly > > > On 6 Oct 2016, at 6:37 am, Rod Rasmussen > <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> wrote: > >> Folks, >> >> Gotta chime in here, since the EWG provided a lot of thinking >> on this issue. If you haven’t already, please review the EWG >> report sections on data accuracy and also the concept of data >> validators and their relationship to the RDS. For example, I >> would note that a well-provisioned RDS would be able to >> provide some sort of validation checks against existing data >> in the use case of trying to prevent impersonation (a form of >> accuracy) of an existing registrant (a big brand like >> Facebook for instance). Another concept we found very >> important in the EWG is the idea of creating a contact data >> set tied to a contact ID that is portable between registrars >> and registries. This provides for the purpose-based contacts >> we talk about at great length in the report. It also is key >> for addressing some of the fundamental operational issues >> that lead to inaccurate, out-of-date data at various >> registrars. If you have a change in your contact information >> (a new e-mail for instance) and hold multiple roles in >> conjunction with many domains, you have a real challenge >> making updates throughout the universe of your domain names. >> Using a data validator and then acting via the RDS, when you >> make a change to your contact info, that automatically can be >> reflected in all domains you are associated with and thus >> improve accuracy tremendously. Those are just a couple >> examples of how an RDS can be involved in dealing with >> accuracy issues and represent many of the concepts you can >> address once you look beyond the current paradigm of >> registrar controlled contact information anchored >> specifically to individual domain names. Accuracy in the >> “generic” system (including registries, registrars, RDS, >> validators, some other group we haven’t thought of yet) is >> definitely in-scope. How that is done can take many forms >> and could have different roles played by different >> participants in the entire ecosystem. >> >> Cheers, >> >> Rod >> >>> On Oct 5, 2016, at 10:36 AM, benny@nordreg.se >>> <mailto:benny@nordreg.se> wrote: >>> >>> But the data accuracy can’t be done in RDS, the accuracy is >>> done on a registrar level when collecting data. >>> RDS shall under no circumstances alter any information >>> received from registry / registrars and showing any >>> different info than what is collected on that level. >>> WG can look at what accuracy they want registrars to do yes, >>> but RDS doesn’t do anything. >>> -- >>> Med vänliga hälsningar / Kind Regards / Med vennlig hilsen >>> >>> Benny Samuelsen >>> Registry Manager - Domainexpert >>> >>> Nordreg AB - ICANN accredited registrar >>> IANA-ID: 638 >>> Phone: +46.42197080 <tel:%2B46.42197080> >>> Direct: +47.32260201 <tel:%2B47.32260201> >>> Mobile: +47.40410200 <tel:%2B47.40410200> >>> *From:*<gnso-rds-pdp-wg-bounces@icann.org >>> <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of >>> "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> >>> *Date:*Wednesday, 5 October 2016 at 19:32 >>> *To:*'Marika Konings' <marika.konings@icann.org >>> <mailto:marika.konings@icann.org>>, Volker Greimann >>> <vgreimann@key-systems.net >>> <mailto:vgreimann@key-systems.net>>, >>> "gnso-rds-pdp-wg@icann.org >>> <mailto:gnso-rds-pdp-wg@icann.org>" >>> <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> >>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated >>> RDS Statement of Purpose >>> Volker, what is the basis for your assertion that “data will >>> be presented "as is" in this system, with no >>> presumption of any prior cleanup work”? >>> That statement will be true if we ultimately conclude that >>> the current system is adequate and that we do not recommend >>> establishment of a new RDS. However, if we do recommend a >>> new system, then improvements to data accuracy are very much >>> on the table, as the charter provision quoted by Marika >>> indicates. >>> Steve Metalitz >>> *From:*gnso-rds-pdp-wg-bounces@icann.org >>> <mailto: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*Marika Konings >>> *Sent:*Wednesday, October 05, 2016 12:53 PM >>> *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org >>> <mailto:gnso-rds-pdp-wg@icann.org> >>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated >>> RDS Statement of Purpose >>> Volker, please note that the PDP WG Charter >>> (seehttps://community.icann.org/x/E4xlAw >>> <https://community.icann.org/x/E4xlAw>) includes the >>> following question: >>> ** >>> */AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach >>> consensusrecommendations byconsidering,*ataminimum*, >>> thefollowingcomplexandinter-related questions:/ >>> /(…..)/ >>> ·*/Data Accuracy:/**//*/Whatstepsshould >>> betakentoimprovedataaccuracy?/ >>> /(……)/ >>> Best regards, >>> Marika >>> On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on >>> behalf of Volker Greimann >>> <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" >>> <gnso-rds-pdp-wg-bounces@icann.org on behalf of >>> vgreimann@key-systems.net >>> <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> >>> wrote: >>> I would move to strike all references to data quality >>> altogether from >>> this document, e.g. "current", "accurate" etc. >>> These are already required by existing policies and >>> agreements and do >>> not have to be referenced again at this point. We should >>> focus on having >>> to reflect the data as provided by the RNH at this >>> stage, not make any >>> presumptions about its quality. >>> After all, data will be presented "as is" in this >>> system, with no >>> presumption of any prior cleanup work. >>> Best, >>> Volker >>> >> THE purpose of the "Registration Data Service" >>> (hereafter referred to >>> >> as >>> >> "RDS") is to manage authorised parties' access to >>> information about >>> >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and >>> gTLD >>> >> Registrars] >>> >> >>> >> Purpose 3(a/b) are possible use cases, not Purposes as such >>> >> >>> >> "Accurate" is definitely not a term to use if we ever >>> expect to finish >>> >> - "Current" would be more accurate (sic) / appropriate. >>> > Agreed, with one minor suggestion: >>> > >>> > "access to information about generic top-level domain >>> registries, registrars, names, and name servers." >>> > >>> > Scott >>> > _______________________________________________ >>> > gnso-rds-pdp-wg mailing list >>> >gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> >>> >https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >>> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg> >>> -- >>> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. >>> Mit freundlichen Grüßen, >>> Volker A. Greimann >>> - Rechtsabteilung - >>> Key-Systems GmbH >>> Im Oberen Werk 1 >>> 66386 St. Ingbert >>> Tel.: +49 (0) 6894 - 9396 901 >>> <tel:%2B49%20%280%29%206894%20-%209396%20901> >>> Fax.: +49 (0) 6894 - 9396 851 >>> <tel:%2B49%20%280%29%206894%20-%209396%20851> >>> Email:vgreimann@key-systems.net >>> <mailto:vgreimann@key-systems.net> >>> Web:www.key-systems.net >>> <http://www.key-systems.net/>/www.RRPproxy.net >>> <http://www.rrpproxy.net/> >>> www.domaindiscount24.com >>> <http://www.domaindiscount24.com/>/www.BrandShelter.com >>> <http://www.brandshelter.com/> >>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei >>> Facebook: >>> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> >>> www.twitter.com/key_systems <http://www.twitter.com/key_systems> >>> Geschäftsführer: Alexander Siffrin >>> Handelsregister Nr.: HR B 18835 - Saarbruecken >>> Umsatzsteuer ID.: DE211006534 >>> Member of the KEYDRIVE GROUP >>> www.keydrive.lu <http://www.keydrive.lu/> >>> Der Inhalt dieser Nachricht ist vertraulich und nur für >>> den angegebenen Empfänger bestimmt. Jede Form der >>> Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte >>> durch den Empfänger ist unzulässig. Sollte diese Nachricht >>> nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns >>> per E-Mail oder telefonisch in Verbindung zu setzen. >>> -------------------------------------------- >>> Should you have any further questions, please do not >>> hesitate to contact us. >>> Best regards, >>> Volker A. Greimann >>> - legal department - >>> Key-Systems GmbH >>> Im Oberen Werk 1 >>> 66386 St. Ingbert >>> Tel.: +49 (0) 6894 - 9396 901 >>> <tel:%2B49%20%280%29%206894%20-%209396%20901> >>> Fax.: +49 (0) 6894 - 9396 851 >>> <tel:%2B49%20%280%29%206894%20-%209396%20851> >>> Email:vgreimann@key-systems.net >>> <mailto:vgreimann@key-systems.net> >>> Web:www.key-systems.net >>> <http://www.key-systems.net/>/www.RRPproxy.net >>> <http://www.rrpproxy.net/> >>> www.domaindiscount24.com >>> <http://www.domaindiscount24.com/>/www.BrandShelter.com >>> <http://www.brandshelter.com/> >>> Follow us on Twitter or join our fan community on >>> Facebook and stay updated: >>> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> >>> www.twitter.com/key_systems <http://www.twitter.com/key_systems> >>> CEO: Alexander Siffrin >>> Registration No.: HR B 18835 - Saarbruecken >>> V.A.T. ID.: DE211006534 >>> Member of the KEYDRIVE GROUP >>> www.keydrive.lu <http://www.keydrive.lu/> >>> This e-mail and its attachments is intended only for the >>> person to whom it is addressed. Furthermore it is not >>> permitted to publish any content of this email. You must not >>> use, disclose, copy, print or rely on this e-mail. If an >>> addressing or transmission error has misdirected this >>> e-mail, kindly notify the author by replying to this e-mail >>> or contacting us by telephone. >>> _______________________________________________ >>> gnso-rds-pdp-wg mailing list >>> gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> >>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >>> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg> >>> _______________________________________________ >>> gnso-rds-pdp-wg mailing list >>> gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> >>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >>> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg> >> >> _______________________________________________ >> gnso-rds-pdp-wg mailing list >> gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> >> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg> > > > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg > <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg> > > > > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg > <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg> > > > > > _______________________________________________ > 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.
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... *Nick Shorey BA(Hons) MSc.* Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels < carlton.samuels@gmail.com> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== *Carlton A Samuels*
*Mobile: 876-818-1799 <876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround* =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
*On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PD**P to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy*
Later - what The Charter tasked this Working Group with:
*As part of its Phase 1 deliberations, **the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:* * Users/Purposes: **Who should have access to gTLD registration data and why?* * Gated Access: **What steps should be taken to control data access for each user/purpose?* * Data Accuracy: **What steps should be taken to improve data accuracy?* * Data Elements: **What data should be collected, stored, and disclosed?* * Privacy: **What steps are needed to protect data and privacy?* * Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?* *Compliance: What steps are needed to enforce these policies?* * System Model:What system requirements must be satisfied by any next-generation RDS implementation?* * Cost: What costs will be incurred and how must they be covered?* * Benefits: What benefits will be achieved and how will they be measured?* * Risks: What risks do stakeholders face and how will they be reconciled?*
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
-- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200
*From: *<gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> *Date: *Wednesday, 5 October 2016 at 19:32 *To: *'Marika Konings' <marika.konings@icann.org>, Volker Greimann < vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" < gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounce s@icann.org <gnso-rds-pdp-wg-bounces@icann.org>] *On Behalf Of *Marika Konings *Sent:* Wednesday, October 05, 2016 12:53 PM *To:* Volker Greimann; gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question:
*As part of its Phase 1 deliberations, **the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:* *(…..)* · *Data Accuracy:* *What steps should be taken to improve data accuracy?* *(……)*
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > 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 <%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851 <%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems 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 <%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851 <%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems 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
_______________________________________________ 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
_______________________________________________ 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 listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Weighing in late… great discussion so far. My comments: Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. Marksv>> I have agree with this statement, at least in principle. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare marksv>> It’s OK for the statement of purpose to state that certain things are out of scope in the first phase, or a subsequent phase, or even forever. I think it would be desirable to state this explicitly, though: “Require accurate data, unless it’s too expensive” or “Provide a low cost path toward greater accuracy of data”, or something along these lines. If the statement of purpose reveals very significant fault lines among the PDP members, those differences must be captured. It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable resources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and resources wasted we spent getting there. Marksv>>> These aren’t good examples, since many or most of us would agree that these activities were frivolous. How about “curing cancer”? That would be an example of something never to be fully achieved but asymptotically approached over time and iterations. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. Marksv>> I agree with Volker on this one. I think our statement of purpose should allow for an iterative process which gradually ages out old data (which may be inaccurate) and gradually replaces it with new data (which is then required to be accurate), and a policy which creates incentives for registries and registrars to improve the quality of the data faster than slower. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Marksv>> To the extent that accurate data is already contractually required, there is a value to anyone who does not desire to be a contract-breaker. Data accuracy above and beyond what is required by contract is a topic for new policy if we desire. I think this contract issue has already been discussed sufficiently elsewhere. From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Nick Shorey Sent: Thursday, October 6, 2016 9:39 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk<mailto:nick.shorey@culture.gov.uk> Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin<http://www.linkedin.com/in/nicklinkedin> On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Greg, Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com<mailto:carlton.samuels@gmail.com>> wrote: +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799<tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: • Users/Purposes: Who should have access to gTLD registration data and why? • Gated Access: What steps should be taken to control data access for each user/purpose? • Data Accuracy: What steps should be taken to improve data accuracy? • Data Elements: What data should be collected, stored, and disclosed? • Privacy: What steps are needed to protect data and privacy? • Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? •Compliance: What steps are needed to enforce these policies? • System Model:What system requirements must be satisfied by any next-generation RDS implementation? • Cost: What costs will be incurred and how must they be covered? • Benefits: What benefits will be achieved and how will they be measured? • Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com<mailto:rrasmussen@infoblox.com>> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, benny@nordreg.se<mailto:benny@nordreg.se> wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080<tel:%2B46.42197080> Direct: +47.32260201<tel:%2B47.32260201> Mobile: +47.40410200<tel:%2B47.40410200> From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com<mailto:met@msk.com>> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org<mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz 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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) • Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris From: "Nick Shorey" <nick.shorey@culture.gov.uk> To: "Volker Greimann" <vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin On 6 October 2016 at 17:23, Volker Greimann < vgreimann@key-systems.net > wrote: Hi Greg, BQ_BEGIN Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare BQ_BEGIN It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. BQ_END One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. BQ_BEGIN We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. BQ_END Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker BQ_BEGIN On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels < carlton.samuels@gmail.com > wrote: BQ_BEGIN +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche < h.raiche@internode.on.net > wrote: BQ_BEGIN Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PD P to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG shoul d work to reach consensus recommendations by considering, at a minimum , the following complex and inter - related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data a ccess for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next - generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model: What system requirements must be satisfied by any next - generat ion RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen < rrasmussen@infoblox.com > wrote: BQ_BEGIN Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod BQ_BEGIN On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200 From: < gnso-rds-pdp-wg-bounces@icann.org > on behalf of "Metalitz, Steven" < met@msk.com > Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' < marika.konings@icann.org >, Volker Greimann < vgreimann@key-systems.net >, " gnso-rds-pdp-wg@icann.org " < gnso-rds-pdp-wg@icann.org > Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “ data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz From: gnso-rds-pdp-wg-bounces@icann.org [ mailto:gnso-rds-pdp-wg-bounces@icann.org ] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw ) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum , the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, " gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann " < gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net > wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > 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 BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END -- 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 BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons: 1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users. 2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data. 3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway? 4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows: To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data. Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Nick Shorey" <nick.shorey@culture.gov.uk> *To: *"Volker Greimann" <vgreimann@key-systems.net> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.* Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <mailto:nick.shorey@culture.gov.uk> Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin>
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com <mailto:carlton.samuels@gmail.com>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 <tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP: / / /On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PD//P to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy/
Later - what The Charter tasked this Working Group with:
/As part of its Phase 1 deliberations, //the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:/ / Users/Purposes: //Who should have access to gTLD registration data and why?/ / Gated Access: //What steps should be taken to control data access for each user/purpose?/ / Data Accuracy: //What steps should be taken to improve data accuracy?/ / Data Elements: //What data should be collected, stored, and disclosed?/ / Privacy: //What steps are needed to protect data and privacy?/ / Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?/ /Compliance: What steps are needed to enforce these policies?/ / System Model:What system requirements must be satisfied by any next-generation RDS implementation?/ / Cost: What costs will be incurred and how must they be covered?/ / Benefits: What benefits will be achieved and how will they be measured?/ / Risks: What risks do stakeholders face and how will they be reconciled?/
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 <tel:%2B46.42197080> Direct: +47.32260201 <tel:%2B47.32260201> Mobile: +47.40410200 <tel:%2B47.40410200> *From:*<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> *Date:*Wednesday, 5 October 2016 at 19:32 *To:*'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz *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*Marika Konings *Sent:*Wednesday, October 05, 2016 12:53 PM *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (seehttps://community.icann.org/x/E4xlAw) includes the following question: ** */AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach consensusrecommendations byconsidering,*ataminimum*, thefollowingcomplexandinter-related questions:/ /(…..)/ ·*/Data Accuracy:/**//*/Whatstepsshould betakentoimprovedataaccuracy?/ /(……)/ Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list >gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> >https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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
There seems to be a presumption that bad data is caused entirely by bad people. Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified? From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons: 1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users. 2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data. 3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway? 4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows: To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data. Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote: Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris ________________________________ From: "Nick Shorey" <nick.shorey@culture.gov.uk><mailto:nick.shorey@culture.gov.uk> To: "Volker Greimann" <vgreimann@key-systems.net><mailto:vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk<mailto:nick.shorey@culture.gov.uk> Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin<http://www.linkedin.com/in/nicklinkedin> On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Greg, Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com<mailto:carlton.samuels@gmail.com>> wrote: +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799<tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com<mailto:rrasmussen@infoblox.com>> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, benny@nordreg.se<mailto:benny@nordreg.se> wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080<tel:%2B46.42197080> Direct: +47.32260201<tel:%2B47.32260201> Mobile: +47.40410200<tel:%2B47.40410200> From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com<mailto:met@msk.com>> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org<mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz 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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) • Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right? SP On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Stephanie Perrin *Sent:* Thursday, October 6, 2016 3:09 PM *To:* gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin
On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------------------------------------------------
*From: *"Nick Shorey" <nick.shorey@culture.gov.uk> <mailto:nick.shorey@culture.gov.uk> *To: *"Volker Greimann" <vgreimann@key-systems.net> <mailto:vgreimann@key-systems.net> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> <mailto:gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.*
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <mailto:nick.shorey@culture.gov.uk>
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin>
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com <mailto:carlton.samuels@gmail.com>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 <tel:876-818-1799> //Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
/On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy/
Later - what The Charter tasked this Working Group with:
/As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:/
/// Users/Purposes: Who should have access to gTLD registration data and why?/
/// Gated Access: What steps should be taken to control data access for each user/purpose?/
/// Data Accuracy: What steps should be taken to improve data accuracy?/
/// Data Elements: What data should be collected, stored, and disclosed?/
/// Privacy: What steps are needed to protect data and privacy?/
/// Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?/
///Compliance: What steps are needed to enforce these policies?/
/// System Model:What system requirements must be satisfied by any next-generation RDS implementation?/
/// Cost: What costs will be incurred and how must they be covered?/
/// Benefits: What benefits will be achieved and how will they be measured?/
/// Risks: What risks do stakeholders face and how will they be reconciled?/
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar
IANA-ID: 638
Phone: +46.42197080 <tel:%2B46.42197080> Direct: +47.32260201 <tel:%2B47.32260201> Mobile: +47.40410200 <tel:%2B47.40410200>
*From:*<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> *Date:*Wednesday, 5 October 2016 at 19:32 *To:*'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no
presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*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*Marika Konings *Sent:*Wednesday, October 05, 2016 12:53 PM *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (seehttps://community.icann.org/x/E4xlAw) includes the following question:
**
*/AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach consensusrecommendations byconsidering,*ataminimum*, thefollowingcomplexandinter-related questions:/
/(…..)/
·*/Data Accuracy:/**//*/Whatstepsshould betakentoimprovedataaccuracy?/
/(……)/
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> gnso-rds-pdp-wg mailing list
>gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
Criminals have a goal of not getting caught. Law enforcement has a goal of catching criminals. They actually succeed quite often. The time, cost and level of success depend on the tools available. Criminals have a goal of ripping people off. Online crime undermines the security of the Internet and reduces consumer/end-user trust and confidence in the Internet. Maintaining the security of the Internet and trust in the Internet is a critical part of ICANN's mission. Our policy recommendations have to support ICANN's mission. The direction in which we need to go seems fairly clear. Greg Shatan On Thursday, October 6, 2016, Stephanie Perrin < stephanie.perrin@mail.utoronto.ca> wrote:
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right?
SP
On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
*From:* gnso-rds-pdp-wg-bounces@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');> [ mailto:gnso-rds-pdp-wg-bounces@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');>] *On Behalf Of *Stephanie Perrin *Sent:* Thursday, October 6, 2016 3:09 PM *To:* gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@icann.org');> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin
On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------
*From: *"Nick Shorey" <nick.shorey@culture.gov.uk> <javascript:_e(%7B%7D,'cvml','nick.shorey@culture.gov.uk');> *To: *"Volker Greimann" <vgreimann@key-systems.net> <javascript:_e(%7B%7D,'cvml','vgreimann@key-systems.net');> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@icann.org');> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.*
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <javascript:_e(%7B%7D,'cvml','nick.shorey@culture.gov.uk');>
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: www.linkedin.com/in/nicklinkedin
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <javascript:_e(%7B%7D,'cvml','vgreimann@key-systems.net');>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels < carlton.samuels@gmail.com <javascript:_e(%7B%7D,'cvml','carlton.samuels@gmail.com');>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== *Carlton A Samuels*
*Mobile: 876-818-1799 <876-818-1799> **Strategy, Planning, Governance, Assessment & Turnaround* =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <javascript:_e(%7B%7D,'cvml','h.raiche@internode.on.net');>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
*On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy*
Later - what The Charter tasked this Working Group with:
*As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:*
*** Users/Purposes: Who should have access to gTLD registration data and why?*
*** Gated Access: What steps should be taken to control data access for each user/purpose?*
*** Data Accuracy: What steps should be taken to improve data accuracy?*
*** Data Elements: What data should be collected, stored, and disclosed?*
*** Privacy: What steps are needed to protect data and privacy?*
*** Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?*
***Compliance: What steps are needed to enforce these policies?*
*** System Model:What system requirements must be satisfied by any next-generation RDS implementation?*
*** Cost: What costs will be incurred and how must they be covered?*
*** Benefits: What benefits will be achieved and how will they be measured?*
*** Risks: What risks do stakeholders face and how will they be reconciled?*
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <javascript:_e(%7B%7D,'cvml','rrasmussen@infoblox.com');>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <javascript:_e(%7B%7D,'cvml','benny@nordreg.se');> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny
+1 Marina A. Lewis marina@dns-law.com<mailto:marina@dns-law.com> (415) 290-1245 On Oct 6, 2016, at 7:47 PM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: Criminals have a goal of not getting caught. Law enforcement has a goal of catching criminals. They actually succeed quite often. The time, cost and level of success depend on the tools available. Criminals have a goal of ripping people off. Online crime undermines the security of the Internet and reduces consumer/end-user trust and confidence in the Internet. Maintaining the security of the Internet and trust in the Internet is a critical part of ICANN's mission. Our policy recommendations have to support ICANN's mission. The direction in which we need to go seems fairly clear. Greg Shatan On Thursday, October 6, 2016, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> wrote: Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right? SP On 2016-10-06 19:20, Mark Svancarek wrote: There seems to be a presumption that bad data is caused entirely by bad people. Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified? From: gnso-rds-pdp-wg-bounces@icann.org<javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');> [mailto:gnso-rds-pdp-wg-bounces@icann.org<javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');>] On Behalf Of Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: gnso-rds-pdp-wg@icann.org<javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@icann.org');> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons: 1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users. 2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data. 3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway? 4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows: To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data. Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote: Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris ________________________________ From: "Nick Shorey" <nick.shorey@culture.gov.uk><javascript:_e(%7B%7D,'cvml','nick.shorey@culture.gov.uk');> To: "Volker Greimann" <vgreimann@key-systems.net><javascript:_e(%7B%7D,'cvml','vgreimann@key-systems.net');> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org><javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@icann.org');> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk<javascript:_e(%7B%7D,'cvml','nick.shorey@culture.gov.uk');> Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin<http://www.linkedin.com/in/nicklinkedin> On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net<javascript:_e(%7B%7D,'cvml','vgreimann@key-systems.net');>> wrote: Hi Greg, Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com<javascript:_e(%7B%7D,'cvml','carlton.samuels@gmail.com');>> wrote: +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799<tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net<javascript:_e(%7B%7D,'cvml','h.raiche@internode.on.net');>> wrote: Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com<javascript:_e(%7B%7D,'cvml','rrasmussen@infoblox.com');>> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, benny@nordreg.se<javascript:_e(%7B%7D,'cvml','benny@nordreg.se');> wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Law enforcement has a goal of catching criminals. They actually succeed quite often. The time, cost and level of success depend on the tools available. Not all tools are legal though. The fruit of the forbidden tree prevents all available tools from being used.
Criminals have a goal of ripping people off. Online crime undermines the security of the Internet and reduces consumer/end-user trust and confidence in the Internet. Depends. There may be cartain criminal uses that are beneficial to more people than detrimental. Opposing the government or publishing secret information may be a criminal act, but stell be in the public benefit.. In those "Robin Hood" cases, the "crime" does not undermine consumer trust in the least bit.
Maintaining the security of the Internet and trust in the Internet is a critical part of ICANN's mission. Agreed. Our policy recommendations have to support ICANN's mission. Right.
The direction in which we need to go seems fairly clear.
Not necessarily as this argument chain contains a logical fallacy.
To borrow from the classic Monty Python sketch the logician: /"Given the premise, 'all fish live underwater' and 'all mackerel are fish', some people will conclude, not that 'all mackerel live underwater', but that 'if she buys kippers it will not rain', or that 'trout live in trees'."/ By your logic, ICANN and by extention the contracted parties would have to become the ultimate internet policeman, preventing crime wherever it looks. That however would be so far outside the scope of ICANNs mission ... By your logic, we would have to set up a PDP to prevent anything that could perceivably harm consumer/end-user trust and confidence in the Internet, such as transactions gone wrong, shipping failures for consumer purchases or even websites with questionable content. Maintaining consumer/end-user trust and confidence in the Internet is important, but as far as it concerns ICANNs mission, its role should remain limited to: 1) Ensuring trust and confidence by making sure the internet technically functions and technical provisions are in place to prevent technical abuse 2) Ensuring trust and confidence by enforcing its agreements (which it does) Best, Volker
Greg Shatan
On Thursday, October 6, 2016, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca <mailto:stephanie.perrin@mail.utoronto.ca>> wrote:
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right?
SP
On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
*From:*gnso-rds-pdp-wg-bounces@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');> [mailto:gnso-rds-pdp-wg-bounces@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');>] *On Behalf Of *Stephanie Perrin *Sent:* Thursday, October 6, 2016 3:09 PM *To:* gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@icann.org');> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin
On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------------------------------------------------
*From: *"Nick Shorey" <nick.shorey@culture.gov.uk> <javascript:_e(%7B%7D,'cvml','nick.shorey@culture.gov.uk');> *To: *"Volker Greimann" <vgreimann@key-systems.net> <javascript:_e(%7B%7D,'cvml','vgreimann@key-systems.net');> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@icann.org');> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.*
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <javascript:_e(%7B%7D,'cvml','nick.shorey@culture.gov.uk');>
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin>
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <javascript:_e(%7B%7D,'cvml','vgreimann@key-systems.net');>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com <javascript:_e(%7B%7D,'cvml','carlton.samuels@gmail.com');>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 <tel:876-818-1799> //Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <javascript:_e(%7B%7D,'cvml','h.raiche@internode.on.net');>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
/On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy/
Later - what The Charter tasked this Working Group with:
/As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:/
/// Users/Purposes: Who should have access to gTLD registration data and why?/
/// Gated Access: What steps should be taken to control data access for each user/purpose?/
/// Data Accuracy: What steps should be taken to improve data accuracy?/
/// Data Elements: What data should be collected, stored, and disclosed?/
/// Privacy: What steps are needed to protect data and privacy?/
/// Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?/
///Compliance: What steps are needed to enforce these policies?/
/// System Model:What system requirements must be satisfied by any next-generation RDS implementation?/
/// Cost: What costs will be incurred and how must they be covered?/
/// Benefits: What benefits will be achieved and how will they be measured?/
/// Risks: What risks do stakeholders face and how will they be reconciled?/
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <javascript:_e(%7B%7D,'cvml','rrasmussen@infoblox.com');>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <javascript:_e(%7B%7D,'cvml','benny@nordreg.se');> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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.
Stephanie Here’s one we run into all the time: A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’. Is the data they supply “bad”? Strictly speaking yes Are they still reachable? Of course they are. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social Random Stuff: http://michele.irish ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> Date: Friday 7 October 2016 at 00:42 To: Mark Svancarek <marksv@microsoft.com>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right? SP On 2016-10-06 19:20, Mark Svancarek wrote: There seems to be a presumption that bad data is caused entirely by bad people. Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified? 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 Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons: 1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users. 2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data. 3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway? 4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows: To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data. Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote: Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris ________________________________ From: "Nick Shorey" <nick.shorey@culture.gov.uk><mailto:nick.shorey@culture.gov.uk> To: "Volker Greimann" <vgreimann@key-systems.net><mailto:vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk<mailto:nick.shorey@culture.gov.uk> Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin<http://www.linkedin.com/in/nicklinkedin> On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Greg, Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com<mailto:carlton.samuels@gmail.com>> wrote: +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799<tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com<mailto:rrasmussen@infoblox.com>> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, benny@nordreg.se<mailto:benny@nordreg.se> wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080<tel:%2B46.42197080> Direct: +47.32260201<tel:%2B47.32260201> Mobile: +47.40410200<tel:%2B47.40410200> From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com<mailto:met@msk.com>> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org<mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz 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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) • Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary. Stephanie On 2016-10-07 08:27, Michele Neylon - Blacknight wrote:
Stephanie
Here’s one we run into all the time:
A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’.
Is the data they supply “bad”? Strictly speaking yes
Are they still reachable? Of course they are.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
http://www.blacknight.press - get our latest news & media coverage
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
Social: http://mneylon.social <http://mneylon.social>
Random Stuff: http://michele.irish <http://michele.irish>
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> *Date: *Friday 7 October 2016 at 00:42 *To: *Mark Svancarek <marksv@microsoft.com>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right?
SP
On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
*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 *Stephanie Perrin *Sent:* Thursday, October 6, 2016 3:09 PM *To:* gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin
On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------------------------------------------------
*From: *"Nick Shorey" <nick.shorey@culture.gov.uk> <mailto:nick.shorey@culture.gov.uk> *To: *"Volker Greimann" <vgreimann@key-systems.net> <mailto:vgreimann@key-systems.net> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> <mailto:gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.*
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <mailto:nick.shorey@culture.gov.uk>
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin>
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com <mailto:carlton.samuels@gmail.com>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 <tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
/On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy/
Later - what The Charter tasked this Working Group with:
/As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:/
/// Users/Purposes: Who should have access to gTLD registration data and why?/
/// Gated Access: What steps should be taken to control data access for each user/purpose?/
/// Data Accuracy: What steps should be taken to improve data accuracy?/
/// Data Elements: What data should be collected, stored, and disclosed?/
/// Privacy: What steps are needed to protect data and privacy?/
/// Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?/
///Compliance: What steps are needed to enforce these policies?/
/// System Model:What system requirements must be satisfied by any next-generation RDS implementation?/
/// Cost: What costs will be incurred and how must they be covered?/
/// Benefits: What benefits will be achieved and how will they be measured?/
/// Risks: What risks do stakeholders face and how will they be reconciled?/
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar
IANA-ID: 638
Phone: +46.42197080 <tel:%2B46.42197080> Direct: +47.32260201 <tel:%2B47.32260201> Mobile: +47.40410200 <tel:%2B47.40410200>
*From:*<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> *Date:*Wednesday, 5 October 2016 at 19:32 *To:*'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no
presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*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*Marika Konings *Sent:*Wednesday, October 05, 2016 12:53 PM *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (seehttps://community.icann.org/x/E4xlAw) includes the following question:
**
*/AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach consensusrecommendations byconsidering,*ataminimum*, thefollowingcomplexandinter-related questions:/
/(…..)/
·*/Data Accuracy:/*/Whatstepsshould betakentoimprovedataaccuracy?/
/(……)/
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> gnso-rds-pdp-wg mailing list
>gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups. We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa. Greg On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin < stephanie.perrin@mail.utoronto.ca> wrote:
Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary.
Stephanie
On 2016-10-07 08:27, Michele Neylon - Blacknight wrote:
Stephanie
Here’s one we run into all the time:
A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’.
Is the data they supply “bad”? Strictly speaking yes
Are they still reachable? Of course they are.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
http://www.blacknight.press - get our latest news & media coverage
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
Social: http://mneylon.social
Random Stuff: http://michele.irish
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org> <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> <stephanie.perrin@mail.utoronto.ca> *Date: *Friday 7 October 2016 at 00:42 *To: *Mark Svancarek <marksv@microsoft.com> <marksv@microsoft.com>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> <gnso-rds-pdp-wg@icann.org> <gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right?
SP
On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org <gnso-rds-pdp-wg-bounces@icann.org>] *On Behalf Of *Stephanie Perrin *Sent:* Thursday, October 6, 2016 3:09 PM *To:* gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin
On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------
*From: *"Nick Shorey" <nick.shorey@culture.gov.uk> <nick.shorey@culture.gov.uk> *To: *"Volker Greimann" <vgreimann@key-systems.net> <vgreimann@key-systems.net> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.*
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: www.linkedin.com/in/nicklinkedin
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels < carlton.samuels@gmail.com> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== *Carlton A Samuels*
*Mobile: 876-818-1799 <876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround* =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
*On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy*
Later - what The Charter tasked this Working Group with:
*As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:*
*** Users/Purposes: Who should have access to gTLD registration data and why?*
*** Gated Access: What steps should be taken to control data access for each user/purpose?*
*** Data Accuracy: What steps should be taken to improve data accuracy?*
*** Data Elements: What data should be collected, stored, and disclosed?*
*** Privacy: What steps are needed to protect data and privacy?*
*** Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?*
***Compliance: What steps are needed to enforce these policies?*
*** System Model:What system requirements must be satisfied by any next-generation RDS implementation?*
*** Cost: What costs will be incurred and how must they be covered?*
*** Benefits: What benefits will be achieved and how will they be measured?*
*** Risks: What risks do stakeholders face and how will they be reconciled?*
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar
IANA-ID: 638
Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200
*From: *<gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> *Date: *Wednesday, 5 October 2016 at 19:32 *To: *'Marika Konings' <marika.konings@icann.org>, Volker Greimann < vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" < gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no
presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org <gnso-rds-pdp-wg-bounces@icann.org>] *On Behalf Of *Marika Konings *Sent:* Wednesday, October 05, 2016 12:53 PM *To:* Volker Greimann; gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann. org/x/E4xlAw) includes the following question:
*As part of its Phase 1 deliberations, **the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:*
*(…..)*
· *Data Accuracy: **What steps should be taken to improve data accuracy?*
*(……)*
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> 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 <http://www.rrpproxy.net/>
www.domaindiscount24.com / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
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 <http://www.rrpproxy.net/>
www.domaindiscount24.com / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________
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
Thats Greg for articulating it so well. all i was going to say was - 'You can’t contact someone if the contact information is inaccurate’ So i can’t see how you can split the two. Richard Leaning External Relations RIPE NCC
On 7 Oct 2016, at 17:21, Greg Shatan <gregshatanipc@gmail.com> wrote:
It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups.
We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa.
Greg
On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca <mailto:stephanie.perrin@mail.utoronto.ca>> wrote: Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary.
Stephanie
On 2016-10-07 08:27, Michele Neylon - Blacknight wrote:
Stephanie
Here’s one we run into all the time:
A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’.
Is the data they supply “bad”? Strictly speaking yes
Are they still reachable? Of course they are.
Regards
Michele
-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ <http://www.blacknight.host/> http://blacknight.blog/ <http://blacknight.blog/> http://www.blacknight.press <http://www.blacknight.press/> - get our latest news & media coverage http://www.technology.ie <http://www.technology.ie/> Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social <http://mneylon.social/> Random Stuff: http://michele.irish <http://michele.irish/> ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
From: <gnso-rds-pdp-wg-bounces@icann.org> <mailto:gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin<stephanie.perrin@mail.utoronto.ca> <mailto:stephanie.perrin@mail.utoronto.ca> Date: Friday 7 October 2016 at 00:42 To: Mark Svancarek <marksv@microsoft.com> <mailto:marksv@microsoft.com>, "gnso-rds-pdp-wg@icann.org" <mailto:gnso-rds-pdp-wg@icann.org> <gnso-rds-pdp-wg@icann.org> <mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right?
SP
On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
<> From: gnso-rds-pdp-wg-bounces@icann.org <mailto: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 Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote: Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
From: "Nick Shorey" <nick.shorey@culture.gov.uk> <mailto:nick.shorey@culture.gov.uk> To: "Volker Greimann" <vgreimann@key-systems.net> <mailto:vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> <mailto:gnso-rds-pdp-wg@icann.org> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <mailto:nick.shorey@culture.gov.uk> Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin>
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com <mailto:carlton.samuels@gmail.com>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 <tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy
Later - what The Charter tasked this Working Group with:
As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled?
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
-- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 <tel:%2B46.42197080> Direct: +47.32260201 <tel:%2B47.32260201> Mobile: +47.40410200 <tel:%2B47.40410200>
From: <gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
From: gnso-rds-pdp-wg-bounces@icann.org <mailto: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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw <https://community.icann.org/x/E4xlAw>) includes the following question:
As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……)
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality.
After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work.
Best, Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net/> / www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/> / www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I’m afraid I disagree, Richard, with the notion that "You can’t contact someone if the contact information is inaccurate." Two values can be different, unambiguous, and allow you to contact someone, but strictly speaking inaccurate. For instance, the data values Myanmar and Burma may both refer to the same country; likewise, the data values Greenwich and Greenwich Village may refer to the same city or neighbourhood. However, the recording of the values is inconsistent. I am sure that any human being looking at these values would have no trouble determining the country or city, but inconsistent values cannot easily be aggregated and compared. I imagine this would cause issues if the RDS was required to take a value and to correlate/compare it to a field in a secondary source of information (how else would we be able to verify a field as accurate? Surely we are not expecting any human verification?) - but I think this is a conversation for another time. Best wishes, Ayden Férdeline [linkedin.com/in/ferdeline](http://www.linkedin.com/in/ferdeline) -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Local Time: 7 October 2016 7:20 PM UTC Time: 7 October 2016 18:20 From: rleaning@ripe.net To: Greg Shatan <gregshatanipc@gmail.com> gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Thats Greg for articulating it so well. all i was going to say was - 'You can’t contact someone if the contact information is inaccurate’ So i can’t see how you can split the two. Richard Leaning External Relations RIPE NCC On 7 Oct 2016, at 17:21, Greg Shatan <gregshatanipc@gmail.com> wrote: It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups. We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa. Greg On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote: Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary. Stephanie On 2016-10-07 08:27, Michele Neylon - Blacknight wrote: Stephanie Here’s one we run into all the time: A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’. Is the data they supply “bad”? Strictly speaking yes Are they still reachable? Of course they are. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ [http://www.blacknight.press](http://www.blacknight.press/) - get our latest news & media coverage [http://www.technology.ie](http://www.technology.ie/) Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: [ http://mneylon.social](http://mneylon.social/) Random Stuff: [ http://michele.irish](http://michele.irish/) ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: [<gnso-rds-pdp-wg-bounces@icann.org>](mailto:gnso-rds-pdp-wg-bounces@icann.org) on behalf of Stephanie Perrin [<stephanie.perrin@mail.utoronto.ca>](mailto:stephanie.perrin@mail.utoronto.ca) Date: Friday 7 October 2016 at 00:42 To: Mark Svancarek [<marksv@microsoft.com>](mailto:marksv@microsoft.com), ["gnso-rds-pdp-wg@icann.org"](mailto:gnso-rds-pdp-wg@icann.org) [<gnso-rds-pdp-wg@icann.org>](mailto:gnso-rds-pdp-wg@icann.org) Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right? SP On 2016-10-06 19:20, Mark Svancarek wrote: There seems to be a presumption that bad data is caused entirely by bad people. Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified? [ ] From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons: 1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users. 2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data. 3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway? 4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows: To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data. Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote: Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris ------ From: "Nick Shorey" [<nick.shorey@culture.gov.uk>](mailto:nick.shorey@culture.gov.uk) To: "Volker Greimann" [<vgreimann@key-systems.net>](mailto:vgreimann@key-systems.net) Cc: "gnso-rds-pdp-wg" [<gnso-rds-pdp-wg@icann.org>](mailto:gnso-rds-pdp-wg@icann.org) Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: [ nick.shorey@culture.gov.uk](mailto:nick.shorey@culture.gov.uk) Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: [ www.linkedin.com/in/nicklinkedin](http://www.linkedin.com/in/nicklinkedin) On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net> wrote: Hi Greg, Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com> wrote: +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: [ 876-818-1799](tel:876-818-1799) Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net> wrote: Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, [ benny@nordreg.se](mailto:benny@nordreg.se) wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: [ +46.42197080](tel:%2B46.42197080) Direct: [+47.32260201](tel:%2B47.32260201) Mobile: [+47.40410200](tel:%2B47.40410200) From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org>, Volker Greimann <vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should workto reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "[gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann](mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann)" <[gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net](mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net)> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to
as
"RDS") is to manage authorised parties' access to information about
[gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish
- "Current" would be more accurate (sic) / appropriate.
Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: [+49 (0) 6894 - 9396 901](tel:%2B49%20%280%29%206894%20-%209396%20901) Fax.: [+49 (0) 6894 - 9396 851](tel:%2B49%20%280%29%206894%20-%209396%20851) Email: vgreimann@key-systems.net Web: [www.key-systems.net](http://www.key-systems.net/) /[www.RRPproxy.net](http://www.rrpproxy.net/) [www.domaindiscount24.com](http://www.domaindiscount24.com/) /[www.BrandShelter.com](http://www.brandshelter.com/) Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP [www.keydrive.lu](http://www.keydrive.lu/) Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: [+49 (0) 6894 - 9396 901](tel:%2B49%20%280%29%206894%20-%209396%20901) Fax.: [+49 (0) 6894 - 9396 851](tel:%2B49%20%280%29%206894%20-%209396%20851) Email: vgreimann@key-systems.net Web: [www.key-systems.net](http://www.key-systems.net/) /[www.RRPproxy.net](http://www.rrpproxy.net/) [www.domaindiscount24.com](http://www.domaindiscount24.com/) /[www.BrandShelter.com](http://www.brandshelter.com/) Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP [www.keydrive.lu](http://www.keydrive.lu/) This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org 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 _______________________________________________ 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 _______________________________________________ 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](tel:%2B49%20%280%29%206894%20-%209396%20901) Fax.: [+49 (0) 6894 - 9396 851](tel:%2B49%20%280%29%206894%20-%209396%20851) Email: vgreimann@key-systems.net Web: [www.key-systems.net](http://www.key-systems.net/) / [www.RRPproxy.net](http://www.rrpproxy.net/) [www.domaindiscount24.com](http://www.domaindiscount24.com/) / [www.BrandShelter.com](http://www.brandshelter.com/) Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP [www.keydrive.lu](http://www.keydrive.lu/) Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: [+49 (0) 6894 - 9396 901](tel:%2B49%20%280%29%206894%20-%209396%20901) Fax.: [+49 (0) 6894 - 9396 851](tel:%2B49%20%280%29%206894%20-%209396%20851) Email: vgreimann@key-systems.net Web: [www.key-systems.net](http://www.key-systems.net/) / [www.RRPproxy.net](http://www.rrpproxy.net/) [www.domaindiscount24.com](http://www.domaindiscount24.com/) / [www.BrandShelter.com](http://www.brandshelter.com/) Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP [www.keydrive.lu](http://www.keydrive.lu/) This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org 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 _______________________________________________ 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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Well the registrar has quite a bit of information about the registrant that is not necessarily in the RDS/WHOIS. SP On 2016-10-07 14:20, Richard Leaning wrote:
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning External Relations RIPE NCC
On 7 Oct 2016, at 17:21, Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> wrote:
It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups.
We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa.
Greg
On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca <mailto:stephanie.perrin@mail.utoronto.ca>> wrote:
Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary.
Stephanie
On 2016-10-07 08:27, Michele Neylon - Blacknight wrote:
Stephanie
Here’s one we run into all the time:
A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’.
Is the data they supply “bad”? Strictly speaking yes
Are they still reachable? Of course they are.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
http://www.blacknight.press <http://www.blacknight.press/> - get our latest news & media coverage
http://www.technology.ie <http://www.technology.ie/>
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
Social: http://mneylon.social <http://mneylon.social/>
Random Stuff: http://michele.irish <http://michele.irish/>
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org> <mailto:gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> <mailto:stephanie.perrin@mail.utoronto.ca> *Date: *Friday 7 October 2016 at 00:42 *To: *Mark Svancarek <marksv@microsoft.com> <mailto:marksv@microsoft.com>, "gnso-rds-pdp-wg@icann.org" <mailto:gnso-rds-pdp-wg@icann.org> <gnso-rds-pdp-wg@icann.org> <mailto:gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right?
SP
On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
*From:*gnso-rds-pdp-wg-bounces@icann.org <mailto: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 *Stephanie Perrin *Sent:* Thursday, October 6, 2016 3:09 PM *To:* gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin
On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------------------------------------------------
*From: *"Nick Shorey" <nick.shorey@culture.gov.uk> <mailto:nick.shorey@culture.gov.uk> *To: *"Volker Greimann" <vgreimann@key-systems.net> <mailto:vgreimann@key-systems.net> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> <mailto:gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.*
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <mailto:nick.shorey@culture.gov.uk>
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin>
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com <mailto:carlton.samuels@gmail.com>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 <tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
/On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy/
Later - what The Charter tasked this Working Group with:
/As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:/
/// Users/Purposes: Who should have access to gTLD registration data and why?/
/// Gated Access: What steps should be taken to control data access for each user/purpose?/
/// Data Accuracy: What steps should be taken to improve data accuracy?/
/// Data Elements: What data should be collected, stored, and disclosed?/
/// Privacy: What steps are needed to protect data and privacy?/
/// Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?/
///Compliance: What steps are needed to enforce these policies?/
/// System Model:What system requirements must be satisfied by any next-generation RDS implementation?/
/// Cost: What costs will be incurred and how must they be covered?/
/// Benefits: What benefits will be achieved and how will they be measured?/
/// Risks: What risks do stakeholders face and how will they be reconciled?/
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar
IANA-ID: 638
Phone: +46.42197080 <tel:%2B46.42197080> Direct: +47.32260201 <tel:%2B47.32260201> Mobile: +47.40410200 <tel:%2B47.40410200>
*From:*<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> *Date:*Wednesday, 5 October 2016 at 19:32 *To:*'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no
presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*From:*gnso-rds-pdp-wg-bounces@icann.org <mailto: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*Marika Konings *Sent:*Wednesday, October 05, 2016 12:53 PM *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (seehttps://community.icann.org/x/E4xlAw <https://community.icann.org/x/E4xlAw>) includes the following question:
**
*/AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach consensusrecommendations byconsidering,*ataminimum*, thefollowingcomplexandinter-related questions:/
/(…..)/
·*/Data Accuracy:/*/Whatstepsshould betakentoimprovedataaccuracy?/
/(……)/
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> gnso-rds-pdp-wg mailing list
>gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/> /www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/> /www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/> /www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/> /www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On Fri, Oct 07, 2016 at 04:15:26PM -0400, Stephanie Perrin wrote:
Well the registrar has quite a bit of information about the registrant that is not necessarily in the RDS/WHOIS.
But _all_ of the information that goes into the RDS comes either via the registrar or the registry. And indeed, _none_ of the information that the registrar or registry is necessarily in the RDS -- our job is to sort out what stuff ought to be available that way (and under what conditions). A -- Andrew Sullivan ajs@anvilwalrusden.com
Or via the validator under the EWG model. :-)
On Oct 7, 2016, at 1:33 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Fri, Oct 07, 2016 at 04:15:26PM -0400, Stephanie Perrin wrote:
Well the registrar has quite a bit of information about the registrant that is not necessarily in the RDS/WHOIS.
But _all_ of the information that goes into the RDS comes either via the registrar or the registry. And indeed, _none_ of the information that the registrar or registry is necessarily in the RDS -- our job is to sort out what stuff ought to be available that way (and under what conditions).
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
That can be used to authenticate / validate Whois data? Shouldn't that be the case? Sent from my iPhone On Oct 7, 2016, at 4:31 PM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> wrote: Well the registrar has quite a bit of information about the registrant that is not necessarily in the RDS/WHOIS. SP On 2016-10-07 14:20, Richard Leaning wrote: Thats Greg for articulating it so well. all i was going to say was - 'You can’t contact someone if the contact information is inaccurate’ So i can’t see how you can split the two. Richard Leaning External Relations RIPE NCC On 7 Oct 2016, at 17:21, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups. We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa. Greg On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> wrote: Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary. Stephanie On 2016-10-07 08:27, Michele Neylon - Blacknight wrote: Stephanie Here’s one we run into all the time: A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’. Is the data they supply “bad”? Strictly speaking yes Are they still reachable? Of course they are. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://www.blacknight.press<http://www.blacknight.press/> - get our latest news & media coverage http://www.technology.ie<http://www.technology.ie/> Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social<http://mneylon.social/> Random Stuff: http://michele.irish<http://michele.irish/> ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: <gnso-rds-pdp-wg-bounces@icann.org><mailto:gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca><mailto:stephanie.perrin@mail.utoronto.ca> Date: Friday 7 October 2016 at 00:42 To: Mark Svancarek <marksv@microsoft.com><mailto:marksv@microsoft.com>, "gnso-rds-pdp-wg@icann.org"<mailto:gnso-rds-pdp-wg@icann.org> <gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right? SP On 2016-10-06 19:20, Mark Svancarek wrote: There seems to be a presumption that bad data is caused entirely by bad people. Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified? 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 Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons: 1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users. 2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data. 3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway? 4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows: To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data. Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote: Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris ________________________________ From: "Nick Shorey" <nick.shorey@culture.gov.uk><mailto:nick.shorey@culture.gov.uk> To: "Volker Greimann" <vgreimann@key-systems.net><mailto:vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk<mailto:nick.shorey@culture.gov.uk> Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin<http://www.linkedin.com/in/nicklinkedin> On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Greg, Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com<mailto:carlton.samuels@gmail.com>> wrote: +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799<tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com<mailto:rrasmussen@infoblox.com>> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, benny@nordreg.se<mailto:benny@nordreg.se> wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080<tel:%2B46.42197080> Direct: +47.32260201<tel:%2B47.32260201> Mobile: +47.40410200<tel:%2B47.40410200> From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com<mailto:met@msk.com>> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org<mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz 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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) • Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Stephanie, I would love as my olive branch put out yesterday to have the ability to authenticate what we have as being true / correct but until the governments of this world get together and suggest/provide a means of proving a person who is registering a domain is in fact the ACTUAL person doing it - the data received cannot be totally 100% accurate. Kind regards, Chris From: "Stephanie Perrin" <stephanie.perrin@mail.utoronto.ca> To: "Richard Leaning" <rleaning@ripe.net>, "Greg Shatan" <gregshatanipc@gmail.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Friday, 7 October, 2016 21:15:26 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Well the registrar has quite a bit of information about the registrant that is not necessarily in the RDS/WHOIS. SP On 2016-10-07 14:20, Richard Leaning wrote: Thats Greg for articulating it so well. all i was going to say was - 'You can’t contact someone if the contact information is inaccurate’ So i can’t see how you can split the two. Richard Leaning External Relations RIPE NCC BQ_BEGIN On 7 Oct 2016, at 17:21, Greg Shatan < gregshatanipc@gmail.com > wrote: It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups. We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa. Greg On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin < stephanie.perrin@mail.utoronto.ca > wrote: BQ_BEGIN Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary. Stephanie On 2016-10-07 08:27, Michele Neylon - Blacknight wrote: BQ_BEGIN Stephanie Here’s one we run into all the time: A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’. Is the data they supply “bad”? Strictly speaking yes Are they still reachable? Of course they are. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social Random Stuff: http://michele.irish ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> Date: Friday 7 October 2016 at 00:42 To: Mark Svancarek <marksv@microsoft.com> , "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right? SP On 2016-10-06 19:20, Mark Svancarek wrote: BQ_BEGIN There seems to be a presumption that bad data is caused entirely by bad people. Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified? From: gnso-rds-pdp-wg-bounces@icann.org [ mailto:gnso-rds-pdp-wg-bounces@icann.org ] On Behalf Of Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons: 1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users. 2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data. 3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway? 4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows: To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data. Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote: BQ_BEGIN Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris From: "Nick Shorey" <nick.shorey@culture.gov.uk> To: "Volker Greimann" <vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin On 6 October 2016 at 17:23, Volker Greimann < vgreimann@key-systems.net > wrote: BQ_BEGIN Hi Greg, BQ_BEGIN Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare BQ_BEGIN It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. BQ_END One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. BQ_BEGIN We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. BQ_END Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker BQ_BEGIN On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels < carlton.samuels@gmail.com > wrote: BQ_BEGIN +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche < h.raiche@internode.on.net > wrote: BQ_BEGIN Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen < rrasmussen@infoblox.com > wrote: BQ_BEGIN Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod BQ_BEGIN On Oct 5, 2016, at 10:36 AM, benny@nordreg.se wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200 From: < gnso-rds-pdp-wg-bounces@icann.org > on behalf of "Metalitz, Steven" < met@msk.com > Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' < marika.konings@icann.org >, Volker Greimann < vgreimann@key-systems.net >, " gnso-rds-pdp-wg@icann.org " < gnso-rds-pdp-wg@icann.org > Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “ data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz From: gnso-rds-pdp-wg-bounces@icann.org [ mailto:gnso-rds-pdp-wg-bounces@icann.org ] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw ) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum , the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, " gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann " < gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net > wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to
as
"RDS") is to manage authorised parties' access to information about
[gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish
- "Current" would be more accurate (sic) / appropriate.
Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
-- 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 BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END -- 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 BQ_END _______________________________________________ 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 BQ_END BQ_END BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I agree Chris, my point to those insisting on accuracy in the actual RDS, is that if someone is a real miscreant (as opposed to someone who forgot to send in a change of address, as most of us have done at some point) the registrars have additional information that would help us track them down. Let us not underestimate what secure ID checking actually costs for governments. Pensioners from several European countries have to go to Canadian Service Canada offices to identify themselves annually, to prove they are alive and still deserve a cheque. Someone has to verify their identity (not so easy) and address, process them, and certify whatever paperwork is required (in this case, I think the employee has to a commissioner of oaths but I could be wrong there.) This is for pension cheques, worth considerably more than a domain name. I realize that the Chinese registration authorities were working on biometric identification of registrants, but I don't think that idea is going to catch on in Europe or North American any time soon. Every time I show up at a hospital in my province, for a test or xray or appointment, they verify the information that I have on file (reading it out to the whole waiting room, a privacy complaint I plan to file as soon I get bored at ICANN). Those minutes of staff time are theoretically justified by the amount of healthcare fraud that goes on, but the nexus between the service and the verification is a lot closer, and once again the financial implications are vastly different. Cheers Stephanie On 2016-10-07 19:22, Chris Pelling wrote:
Hi Stephanie,
I would love as my olive branch put out yesterday to have the ability to authenticate what we have as being true / correct but until the governments of this world get together and suggest/provide a means of proving a person who is registering a domain is in fact the ACTUAL person doing it - the data received cannot be totally 100% accurate.
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Stephanie Perrin" <stephanie.perrin@mail.utoronto.ca> *To: *"Richard Leaning" <rleaning@ripe.net>, "Greg Shatan" <gregshatanipc@gmail.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Friday, 7 October, 2016 21:15:26 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Well the registrar has quite a bit of information about the registrant that is not necessarily in the RDS/WHOIS.
SP
On 2016-10-07 14:20, Richard Leaning wrote:
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning External Relations RIPE NCC
On 7 Oct 2016, at 17:21, Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> wrote:
It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups.
We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa.
Greg
On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca <mailto:stephanie.perrin@mail.utoronto.ca>> wrote:
Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary.
Stephanie
On 2016-10-07 08:27, Michele Neylon - Blacknight wrote:
Stephanie
Here’s one we run into all the time:
A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’.
Is the data they supply “bad”? Strictly speaking yes
Are they still reachable? Of course they are.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
http://www.blacknight.press <http://www.blacknight.press/> - get our latest news & media coverage
http://www.technology.ie <http://www.technology.ie/>
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
Social: http://mneylon.social <http://mneylon.social/>
Random Stuff: http://michele.irish <http://michele.irish/>
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org> <mailto:gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> <mailto:stephanie.perrin@mail.utoronto.ca> *Date: *Friday 7 October 2016 at 00:42 *To: *Mark Svancarek <marksv@microsoft.com> <mailto:marksv@microsoft.com>, "gnso-rds-pdp-wg@icann.org" <mailto:gnso-rds-pdp-wg@icann.org> <gnso-rds-pdp-wg@icann.org> <mailto:gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right?
SP
On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
*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 *Stephanie Perrin *Sent:* Thursday, October 6, 2016 3:09 PM *To:* gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin
On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------------------------------------------------
*From: *"Nick Shorey" <nick.shorey@culture.gov.uk> <mailto:nick.shorey@culture.gov.uk> *To: *"Volker Greimann" <vgreimann@key-systems.net> <mailto:vgreimann@key-systems.net> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> <mailto:gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.*
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <mailto:nick.shorey@culture.gov.uk>
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin>
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com <mailto:carlton.samuels@gmail.com>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 <tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
/On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy/
Later - what The Charter tasked this Working Group with:
/As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:/
/// Users/Purposes: Who should have access to gTLD registration data and why?/
/// Gated Access: What steps should be taken to control data access for each user/purpose?/
/// Data Accuracy: What steps should be taken to improve data accuracy?/
/// Data Elements: What data should be collected, stored, and disclosed?/
/// Privacy: What steps are needed to protect data and privacy?/
/// Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?/
///Compliance: What steps are needed to enforce these policies?/
/// System Model:What system requirements must be satisfied by any next-generation RDS implementation?/
/// Cost: What costs will be incurred and how must they be covered?/
/// Benefits: What benefits will be achieved and how will they be measured?/
/// Risks: What risks do stakeholders face and how will they be reconciled?/
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar
IANA-ID: 638
Phone: +46.42197080 <tel:%2B46.42197080> Direct: +47.32260201 <tel:%2B47.32260201> Mobile: +47.40410200 <tel:%2B47.40410200>
*From:*<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> *Date:*Wednesday, 5 October 2016 at 19:32 *To:*'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no
presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*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*Marika Konings *Sent:*Wednesday, October 05, 2016 12:53 PM *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (seehttps://community.icann.org/x/E4xlAw) includes the following question:
**
*/AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach consensusrecommendations byconsidering,*ataminimum*, thefollowingcomplexandinter-related questions:/
/(…..)/
·*/Data Accuracy:/*/Whatstepsshould betakentoimprovedataaccuracy?/
/(……)/
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> gnso-rds-pdp-wg mailing list
>gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/> /www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/> /www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/> /www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/> /www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Indeed, and I don't suppose anyone would dispute that. But note that some of this information, although it does not go into the current Whois, is under the RAA, subject to verification, specifically, the Account holder (generally the entity that pays for the domains if not the same as the registrant). Alan At 07/10/2016 04:15 PM, Stephanie Perrin wrote:
Well the registrar has quite a bit of information about the registrant that is not necessarily in the RDS/WHOIS.
SP
On 2016-10-07 14:20, Richard Leaning wrote:
Thats Greg for articulating it so well.
all i was going to say was -
'You canât contact someone if the contact information is inaccurateâ
So i canât see how you can split the two.
Richard Leaning External Relations RIPE NCC
On 7 Oct 2016, at 17:21, Greg Shatan <<mailto:gregshatanipc@gmail.com>gregshatanipc@gmail.com> wrote:
It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups.
We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa.
Greg
On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin <<mailto:stephanie.perrin@mail.utoronto.ca>stephanie.perrin@mail.utoronto.ca> wrote:
Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary.
Stephanie
On 2016-10-07 08:27, Michele Neylon - Blacknight wrote:
Stephanie
Hereâs one we run into all the time:
A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so theyâll choose to list their country as âIrelandâ.
Is the data they supply âbadâ? Strictly speaking yes
Are they still reachable? Of course they are.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
<http://www.blacknight.host/>http://www.blacknight.host/
<http://www.blacknight.press/>http://www.blacknight.press - get our latest news & media coverage
<http://www.technology.ie/>http://www.technology.ie
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
Social: <http://mneylon.social/>http://mneylon.social
Random Stuff: <http://michele.irish/>http://michele.irish
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
From: <mailto:gnso-rds-pdp-wg-bounces@icann.org><gnso-rds-pdp-wg-bounces@icann.org> on behalf of Stephanie Perrin <mailto:stephanie.perrin@mail.utoronto.ca><stephanie.perrin@mail.utoronto.ca> Date: Friday 7 October 2016 at 00:42 To: Mark Svancarek <mailto:marksv@microsoft.com><marksv@microsoft.com>, <mailto:gnso-rds-pdp-wg@icann.org>"gnso-rds-pdp-wg@icann.org" <mailto:gnso-rds-pdp-wg@icann.org><gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right?
SP
On 2016-10-06 19:20, Mark Svancarek wrote:
There seems to be a presumption that bad data is caused entirely by bad people.
Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified?
From: <mailto:gnso-rds-pdp-wg-bounces@icann.org>gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons:
1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users.
2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data.
3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway?
4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows:
To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to
To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data.
Stephanie Perrin
On 2016-10-06 16:48, Chris Pelling wrote:
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
---------- From: "Nick Shorey" <mailto:nick.shorey@culture.gov.uk><nick.shorey@culture.gov.uk> To: "Volker Greimann" <mailto:vgreimann@key-systems.net><vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <mailto:gnso-rds-pdp-wg@icann.org><gnso-rds-pdp-wg@icann.org> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
Nick Shorey BA(Hons) MSc.
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: <mailto:nick.shorey@culture.gov.uk>nick.shorey@culture.gov.uk
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: <http://www.linkedin.com/in/nicklinkedin>www.linkedin.com/in/nicklinkedin
On 6 October 2016 at 17:23, Volker Greimann <<mailto:vgreimann@key-systems.net>vgreimann@key-systems.net> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <<mailto:carlton.samuels@gmail.com>carlton.samuels@gmail.com> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== Carlton A Samuels Mobile: <tel:876-818-1799>876-818-1799 Strategy, Planning, Governance, Assessment & Turnaround =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <<mailto:h.raiche@internode.on.net>h.raiche@internode.on.net> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWGâs Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy
Later - what The Charter tasked this Working Group with:
As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:
ï· Users/Purposes: Who should have access to gTLD registration data and why?
ï· Gated Access: What steps should be taken to control data access for each user/purpose?
ï· Data Accuracy: What steps should be taken to improve data accuracy?
ï· Data Elements: What data should be collected, stored, and disclosed?
ï· Privacy: What steps are needed to protect data and privacy?
ï· Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?
ï·Compliance: What steps are needed to enforce these policies?
ï· System Model:What system requirements must be satisfied by any next-generation RDS implementation?
ï· Cost: What costs will be incurred and how must they be covered?
ï· Benefits: What benefits will be achieved and how will they be measured?
ï· Risks: What risks do stakeholders face and how will they be reconciled?
So accuracyâs there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., itâs not just about collection, maintenance and access to data; itâs also about safeguards, etc - using the EWG work.
So thanks Rob. Itâs a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <<mailto:rrasmussen@infoblox.com>rrasmussen@infoblox.com> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you havenât already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the âgenericâ system (including registries, registrars, RDS, validators, some other group we havenât thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, <mailto:benny@nordreg.se>benny@nordreg.se wrote:
But the data accuracy canât be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesnât do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar
IANA-ID: 638
Phone: <tel:%2B46.42197080>+46.42197080 Direct: <tel:%2B47.32260201>+47.32260201 Mobile: <tel:%2B47.40410200>+47.40410200
From: <<mailto:gnso-rds-pdp-wg-bounces@icann.org>gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <<mailto:met@msk.com>met@msk.com> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <<mailto:marika.konings@icann.org>marika.konings@icann.org>, Volker Greimann <<mailto:vgreimann@key-systems.net>vgreimann@key-systems.net>, "<mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org" <<mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that âdata will be presented "as is" in this system, with no
presumption of any prior cleanup workâ?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
From: <mailto:gnso-rds-pdp-wg-bounces@icann.org>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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see <https://community.icann.org/x/E4xlAw>https://community.icann.org/x/E4xlAw) includes the following question:
As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:
( ..)
· Data Accuracy: What steps should be taken to improve data accuracy?
( )
Best regards,
Marika
On 05/10/16 05:58, "<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann" <<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> <mailto:gnso-rds-pdp-wg@icann.org>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.: <tel:%2B49%20%280%29%206894%20-%209396%20901>+49 (0) 6894 - 9396 901
Fax.: <tel:%2B49%20%280%29%206894%20-%209396%20851>+49 (0) 6894 - 9396 851
Email: <mailto:vgreimann@key-systems.net>vgreimann@key-systems.net
Web: <http://www.key-systems.net/>www.key-systems. net / <http://www.rrpproxy.net/>www.RRPproxy.net
<http://www.domaindiscount24.com/>www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<http://www.facebook.com/KeySystems>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
<http://www.keydrive.lu/>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.: <tel:%2B49%20%280%29%206894%20-%209396%20901>+49 (0) 6894 - 9396 901
Fax.: <tel:%2B49%20%280%29%206894%20-%209396%20851>+49 (0) 6894 - 9396 851
Email: <mailto:vgreimann@key-systems.net>vgreimann@key-systems.net
Web: <http://www.key-systems.net/>www.key-systems. net / <http://www.rrpproxy.net/>www.RRPproxy.net
<http://www.domaindiscount24.com/>www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
<http://www.facebook.com/KeySystems>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
<http://www.keydrive.lu/>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
<mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
<mailto:gnso-rds-pdp-wg@icann.org>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.: <tel:%2B49%20%280%29%206894%20-%209396%20901>+49 (0) 6894 - 9396 901
Fax.: <tel:%2B49%20%280%29%206894%20-%209396%20851>+49 (0) 6894 - 9396 851
Email: <mailto:vgreimann@key-systems.net>vgreimann@key-systems.net
Web: <http://www.key-systems.net/>www.key-systems.net / www.RRPproxy.net
<http://www.domaindiscount24.com/>www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<http://www.facebook.com/KeySystems>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
<http://www.keydrive.lu/>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.: <tel:%2B49%20%280%29%206894%20-%209396%20901>+49 (0) 6894 - 9396 901
Fax.: <tel:%2B49%20%280%29%206894%20-%209396%20851>+49 (0) 6894 - 9396 851
Email: <mailto:vgreimann@key-systems.net>vgreimann@key-systems.net
Web: <http://www.key-systems.net/>www.key-systems.net / www.RRPproxy.net
<http://www.domaindiscount24.com/>www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
<http://www.facebook.com/KeySystems>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
<http://www.keydrive.lu/>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 <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
<mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org
_______________________________________________ gnso-rds-pdp-wg mailing list <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list <mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Microsoft-Exchange-Diagnostics:
1;DM5PR03MB2714;9:hkNhvlOvFsYxQ1pp43Ml6KkLx8C96LgnO+RBWv02aNRTWJ6pleWnSxqUBxU8/Okp39l1SudWSL2MtPsLkJaKANhWvy+zW3FgkKIEqT46rrXWHfA5TgKiRe0JlV59h0YUXgGMxc3jIbJaRcwpTi7IQ6k16JliXX07xSVMhGm6dO2iW+zz+X1bDN++4OdQQ/bpbOr30w7KdTqntJ9nDjk0IDp5yEscQGvK1/+2657iPLHWgh1M9TKGurpyB6sU72WSV7eq9aCcJEpigFnRxg1m8HUsaaPkocDa7Nc2d3gtkl2R6G6CTvX+/HtEmI2BiMn4Z1EeccMX3YQxNHy2ZFo02C7qrWRCD6JERnkmPs0sbsV7A7Qfl7wNNFYThQfZNz1sXyOOTlB/QBAwCcRwuPpPRHR4Fei/zhEYc2szAwLHc+JoyXfo406A3Gda+XbfT02f X-Microsoft-Antispam-Mailbox-Delivery: ex:0;auth:0;dest:I;ENG:(20160514016)(520000050)(520002050)(750028);
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On 2016-10-07 19:20, Richard Leaning wrote:
'You can’t contact someone if the contact information is inaccurate’ So i can’t see how you can split the two.
"Accuracy" and "Working" are not synonomous though. It wouldn't be accurate to use my previous home address, but I can still be contacted (as the post is redirected and I know the occupants) It wouldn't be accurate to use the local Subways as my address, but I can still be contacted, as they know me and my regular breakfast foot-long sub It wouldn't be accurate to have our tech office address without the "East India Dock" part, but most web-based forms dont allow for 3 lines of address before the town , yet I'm not aware of the post office ever not delivering anything where that isn't supplied And so on. A goal of being able to _reach_ a registrant is different to a goal of having 100% accurate information - might just be semantics but I think the difference is important. Rob
Dick Sorry, but that’s absolutely untrue. So I agree with Greg. I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times. Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me. There is a very big difference between “functional” and “accurate”. As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address. Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265, Ireland Company No.: 370845 From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Richard Leaning <rleaning@ripe.net> Date: Friday 7 October 2016 at 19:20 To: Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Thats Greg for articulating it so well. all i was going to say was - 'You can’t contact someone if the contact information is inaccurate’ So i can’t see how you can split the two. Richard Leaning External Relations RIPE NCC
Michele, I don't disagree with you. There will always be scenarios where common sense prevails. But if you want to phone me you will need the accurate number - not something that looks like my number. If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address. All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try. Cheers Dick Richard Leaning RIPE NCC External Relations (Sent by iPhone)
On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight <michele@blacknight.com> wrote:
Dick
Sorry, but that’s absolutely untrue. So I agree with Greg.
I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times. Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me.
There is a very big difference between “functional” and “accurate”.
As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address.
Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois.
Regards
Michele
-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265, Ireland Company No.: 370845
From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Richard Leaning <rleaning@ripe.net> Date: Friday 7 October 2016 at 19:20 To: Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning External Relations RIPE NCC
HI Dick, I think you will find that all registrars will already strive for accuracy as best they can, certainly when it comes to email address and/or phone depending on what they use to validate. In your point regarding reaching you by phone or email, I sort of agree, but disagree, if someone truly (and this is in respect to you as you stated yourself) wants to get hold of you, a very small bit of investigation with Google would give Ripe's number and a call to Ripe would in one way shapr or another get ahold of you. -- Edge case I know, but I was directly responding to that point. I suppose at some point in the future I am sure the same discussions our group is having will trickle down the IANA side of things in relation to RiR's moving over to RDS and having the same data issues we are currently discussing. :) Kind regards, Chris From: "Richard Leaning" <rleaning@ripe.net> To: "Michele Neylon" <michele@blacknight.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Sunday, 9 October, 2016 18:09:39 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Michele, I don't disagree with you. There will always be scenarios where common sense prevails. But if you want to phone me you will need the accurate number - not something that looks like my number. If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address. All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try. Cheers Dick Richard Leaning RIPE NCC External Relations (Sent by iPhone) On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight < michele@blacknight.com > wrote: Dick Sorry, but that’s absolutely untrue. So I agree with Greg. I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times. Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me. There is a very big difference between “functional” and “accurate”. As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address. Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265, Ireland Company No.: 370845 From: < gnso-rds-pdp-wg-bounces@icann.org > on behalf of Richard Leaning < rleaning@ripe.net > Date: Friday 7 October 2016 at 19:20 To: Greg Shatan < gregshatanipc@gmail.com > Cc: gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org > Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Thats Greg for articulating it so well. all i was going to say was - 'You can’t contact someone if the contact information is inaccurate’ So i can’t see how you can split the two. Richard Leaning External Relations RIPE NCC _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Going back to my earlier post, not all contact data is equally fault-tolerant. Some can be resilient, some can be brittle. Data needs to be looked at in context as well. Looking just at the dataset of contact data we see in WHOIS, some mistakes or missing data will result in non-contactability, while other mistakes or missing data can be worked around with other data in the dataset. For example, take my old phone number -- 1-212-995-2768. In one sense, phone numbers are not at all fault tolerant -- if you don't have all the numbers right, you will not get through. In another sense, some parts of a phone number are fault tolerant, while others are not. For instance, if you have a missing country code (1) but you have the area code or my address, you can easily solve the missing country code problem. If you're missing the area code, that's a bigger problem. Assuming it's a landline and the area code is an accurate reflection of geography, you could like at the address; however, my physical address has 3 possible area codes, so that's not so simple. If it were a mobile number, the missing area code could be fatal, since my physical address could be anywhere in the world. If any of the last 7 numbers are missing or inaccurate, that's fatal in terms of "mechanical" solutions coming from the rest of the dataset. Finally, note that I said this was my *old* phone number -- even if all the numbers are right you won't be able to reach me, because it's an old number and calling it only tells you the number is no longer in service. Physical addresses can also be fault tolerant, to an extent, without going beyond the dataset. First, some information isn't entirely necessary. You can leave out my zip code and I'll still get the mail, perhaps a day or two late if it gets bumped out to manual sorting, because the remaining information is sufficient. Similarly, you can leave my apartment number off, and I'll probably still get it, but it's no longer a certainty (I leave in a 140-unit building and our regular mailman probably know which apartment I'm in, but a substitute might not.). Leave out my street name and I won't get it, even if all the other information is correct, because the remaining information is insufficient. Similarly, because I live in New York City, you could leave out the state, but if I lived in Middletown, NY, you can't, because there's a Middletown in the majority of US states. Analysis of fault tolerance of particular data or using other data within the dataset is appropriate in my view. However, I don't think it's appropriate in our context to look at external solutions to determine whether data is "functionally accurate," whether it's Googling it, figuring it out or hiring a private detective (or being a detective). This takes us out of the realm of self-sufficient solutions, and in most cases, takes us out of the realm of automated solutions, bringing in the use of human resources on a case-by-case basis. It also takes us largely out of the realm of rules-based solutions. These fuzzy factors make it impossible to characterize any data type as functionally accurate, because it depends on unknowns (as far as the data at hand goes) in order to resolve an issue, if it can be resolved at all. Even if contact can be can be resolved in spite of the missing datum, the time, effort and cost involved in doing so are orders of magnitude higher than a solution using other data in the dataset. Finally, I may be too cavalier regarding the ability to resolve missing data using other data in the dataset. It can depend on the user and the purpose, and whether contact using fully accurate data is done in a mechanized fashion for that user and purpose. It also depends on the workflows and the capability to develop methods to apply the remaining data to solve the problem posed by missing data. I've assumed something of a reasonable best case scenario in that regard, and skewed my thoughts to uses I'm more familiar with; as a result, my working assumptions regarding functional accuracy and the use of other data in the dataset (or proceeding without certain data) may be too optimistic. Greg On Sun, Oct 9, 2016 at 3:05 PM, Chris Pelling <chris@netearth.net> wrote:
HI Dick,
I think you will find that all registrars will already strive for accuracy as best they can, certainly when it comes to email address and/or phone depending on what they use to validate.
In your point regarding reaching you by phone or email, I sort of agree, but disagree, if someone truly (and this is in respect to you as you stated yourself) wants to get hold of you, a very small bit of investigation with Google would give Ripe's number and a call to Ripe would in one way shapr or another get ahold of you. -- Edge case I know, but I was directly responding to that point.
I suppose at some point in the future I am sure the same discussions our group is having will trickle down the IANA side of things in relation to RiR's moving over to RDS and having the same data issues we are currently discussing. :)
Kind regards,
Chris
------------------------------ *From: *"Richard Leaning" <rleaning@ripe.net> *To: *"Michele Neylon" <michele@blacknight.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Sunday, 9 October, 2016 18:09:39
*Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Michele,
I don't disagree with you. There will always be scenarios where common sense prevails.
But if you want to phone me you will need the accurate number - not something that looks like my number.
If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address.
All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try.
Cheers
Dick
Richard Leaning RIPE NCC External Relations (Sent by iPhone)
On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight < michele@blacknight.com> wrote:
Dick
Sorry, but that’s absolutely untrue. So I agree with Greg.
I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times.
Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me.
There is a very big difference between “functional” and “accurate”.
As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address.
Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,
Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org> on behalf of Richard Leaning < rleaning@ripe.net> *Date: *Friday 7 October 2016 at 19:20 *To: *Greg Shatan <gregshatanipc@gmail.com> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning
External Relations
RIPE NCC
_______________________________________________ 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
I agree there Greg, you need to look at the context of the data, I like the examples. What is missing is a database so you can cross check the data. And there lies the problem, there is no such database or tool available. You would think if there is a commercial solution out there we would have already started using that right? Such a tool would be used all over I guess. But we don't, because it does not exist. Sure Fedex works nicely, and they usually deliver most of the stuff you order, but there are countries they heavily need to rely on asking directions, yes real old school. Accuracy is important, the examples here are countless, but accuracy should not be confused with trying to achieve the impossible. Accuracy should be a realistic goal. I think most of us are on the same page here. Best Theo On 9-10-2016 22:12, Greg Shatan wrote:
Going back to my earlier post, not all contact data is equally fault-tolerant. Some can be resilient, some can be brittle. Data needs to be looked at in context as well. Looking just at the dataset of contact data we see in WHOIS, some mistakes or missing data will result in non-contactability, while other mistakes or missing data can be worked around with other data in the dataset.
For example, take my old phone number -- 1-212-995-2768. In one sense, phone numbers are not at all fault tolerant -- if you don't have all the numbers right, you will not get through. In another sense, some parts of a phone number are fault tolerant, while others are not. For instance, if you have a missing country code (1) but you have the area code or my address, you can easily solve the missing country code problem. If you're missing the area code, that's a bigger problem. Assuming it's a landline and the area code is an accurate reflection of geography, you could like at the address; however, my physical address has 3 possible area codes, so that's not so simple. If it were a mobile number, the missing area code could be fatal, since my physical address could be anywhere in the world. If any of the last 7 numbers are missing or inaccurate, that's fatal in terms of "mechanical" solutions coming from the rest of the dataset. Finally, note that I said this was my _old_ phone number -- even if all the numbers are right you won't be able to reach me, because it's an old number and calling it only tells you the number is no longer in service.
Physical addresses can also be fault tolerant, to an extent, without going beyond the dataset. First, some information isn't entirely necessary. You can leave out my zip code and I'll still get the mail, perhaps a day or two late if it gets bumped out to manual sorting, because the remaining information is sufficient. Similarly, you can leave my apartment number off, and I'll probably still get it, but it's no longer a certainty (I leave in a 140-unit building and our regular mailman probably know which apartment I'm in, but a substitute might not.). Leave out my street name and I won't get it, even if all the other information is correct, because the remaining information is insufficient. Similarly, because I live in New York City, you could leave out the state, but if I lived in Middletown, NY, you can't, because there's a Middletown in the majority of US states.
Analysis of fault tolerance of particular data or using other data within the dataset is appropriate in my view. However, I don't think it's appropriate in our context to look at external solutions to determine whether data is "functionally accurate," whether it's Googling it, figuring it out or hiring a private detective (or being a detective). This takes us out of the realm of self-sufficient solutions, and in most cases, takes us out of the realm of automated solutions, bringing in the use of human resources on a case-by-case basis. It also takes us largely out of the realm of rules-based solutions. These fuzzy factors make it impossible to characterize any data type as functionally accurate, because it depends on unknowns (as far as the data at hand goes) in order to resolve an issue, if it can be resolved at all. Even if contact can be can be resolved in spite of the missing datum, the time, effort and cost involved in doing so are orders of magnitude higher than a solution using other data in the dataset.
Finally, I may be too cavalier regarding the ability to resolve missing data using other data in the dataset. It can depend on the user and the purpose, and whether contact using fully accurate data is done in a mechanized fashion for that user and purpose. It also depends on the workflows and the capability to develop methods to apply the remaining data to solve the problem posed by missing data. I've assumed something of a reasonable best case scenario in that regard, and skewed my thoughts to uses I'm more familiar with; as a result, my working assumptions regarding functional accuracy and the use of other data in the dataset (or proceeding without certain data) may be too optimistic.
Greg
On Sun, Oct 9, 2016 at 3:05 PM, Chris Pelling <chris@netearth.net <mailto:chris@netearth.net>> wrote:
HI Dick,
I think you will find that all registrars will already strive for accuracy as best they can, certainly when it comes to email address and/or phone depending on what they use to validate.
In your point regarding reaching you by phone or email, I sort of agree, but disagree, if someone truly (and this is in respect to you as you stated yourself) wants to get hold of you, a very small bit of investigation with Google would give Ripe's number and a call to Ripe would in one way shapr or another get ahold of you. -- Edge case I know, but I was directly responding to that point.
I suppose at some point in the future I am sure the same discussions our group is having will trickle down the IANA side of things in relation to RiR's moving over to RDS and having the same data issues we are currently discussing. :)
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Richard Leaning" <rleaning@ripe.net <mailto:rleaning@ripe.net>> *To: *"Michele Neylon" <michele@blacknight.com <mailto:michele@blacknight.com>> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Sunday, 9 October, 2016 18:09:39
*Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Michele,
I don't disagree with you. There will always be scenarios where common sense prevails.
But if you want to phone me you will need the accurate number - not something that looks like my number.
If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address.
All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try.
Cheers
Dick
Richard Leaning RIPE NCC External Relations (Sent by iPhone)
On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight <michele@blacknight.com <mailto:michele@blacknight.com>> wrote:
Dick
Sorry, but that’s absolutely untrue. So I agree with Greg.
I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times.
Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me.
There is a very big difference between “functional” and “accurate”.
As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address.
Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072 <tel:%2B353%20%280%29%2059%20%C2%A09183072>
Direct Dial: +353 (0)59 9183090 <tel:%2B353%20%280%2959%209183090>
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,
Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Richard Leaning <rleaning@ripe.net <mailto:rleaning@ripe.net>> *Date: *Friday 7 October 2016 at 19:20 *To: *Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning
External Relations
RIPE NCC
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I still do not agree: A phone n umber may be technically incorrect but still functional. Consider these examples: 0049-1234-56789 +49-123456789 +49.0123456789 0049(0)123456789 and variations thereof. All of these numbers will be readily usabla for anyone with half a brain cell, yet each and every one of these numbers is inaccurate under wcurrent whois policies. For reference, this would be the "correct" number: +49.123456789 So what does this tell us? It tells me that on the march to accuracy, we will create more issues than we will solve. I have seen mail delivered to horribly spelled addresses, yet otoh, I have also seen time and again that mail sent to perfectly correct addresses was not delivered, because the postman could not find it (for example because the entrance to a building in one street actually was located around the corner in another street) and the mail was returned undelivered. Best, Volker Am 09.10.2016 um 19:09 schrieb Richard Leaning:
Michele,
I don't disagree with you. There will always be scenarios where common sense prevails.
But if you want to phone me you will need the accurate number - not something that looks like my number.
If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address.
All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try.
Cheers
Dick
Richard Leaning RIPE NCC External Relations (Sent by iPhone)
On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight <michele@blacknight.com <mailto:michele@blacknight.com>> wrote:
Dick
Sorry, but that’s absolutely untrue. So I agree with Greg.
I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times.
Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me.
There is a very big difference between “functional” and “accurate”.
As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address.
Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,
Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Richard Leaning <rleaning@ripe.net <mailto:rleaning@ripe.net>> *Date: *Friday 7 October 2016 at 19:20 *To: *Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning
External Relations
RIPE NCC
_______________________________________________ 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.
In the post below, Volker is talking about data FORMATTING, not ACCURACY. Formatting and accuracy are distinct concepts. They can have a relationship, but they are not one and the same. It is very important to understand the difference. Formatting is the way in which something is arranged or set out. For example, do you format country name in the written-out form ("Canada"), or do you use the two-letter abbreviation ("CA")? Either way the data is accurate; you know the contact is in Canada. The formatting of many registration data fields is specified in the EPP RFCs, which registries and registrars have been required to follow for years. For example, RFC5733 says registries and registrars must use certain standard conventions for timestamps, use email address syntax as per RFC5322, use two-character country codes per ISO standards, and must format contact telephone numbers a certain way derived from international standards. The benefits of standardized data formatting are obvious, and RFCs are designed to bring those benefits to the Internet. In the case of EPP, registries and registrars can store and trade data easily and accurately. As the SSAC has noted, these standards make it easier for people and applications to understand and use registration data (SAC051). The 2013 RAA requires that registrars validate that certain data fields are FORMATTED CORRECTLY as per the standards. In SAC058, the SSAC described it this way: "Syntactic Validation refers to the assessment of data with the intent to ensure that they satisfy specified syntactic constraints, conform to specified data standards, and are transformed and formatted properly for their intended use." Validating that the data is ACCURATE -- that it's truthful, or that an address is deliverable, or is suitable for operational purposes, or however you want to say it -- is a different concept. Validation of accuracy has different procedures and can have different standards. For more about that, please see the sections about Operational Validation and Identity Validation in SAC058. https://www.icann.org/en/system/files/files/sac-058-en.pdf The 2013 contains an operational validation requirement. Recommendation 1 from SAC058 was: "The SSAC recommends that the ICANN community should consider adopting the terminology outlined in this report in documents and discussions." The RDS WG should discuss that. We have protocol standards so that things will work, and RFCs should be adhered to. Hopefully that is uncontroversial. With best wishes, --Greg From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Volker Greimann Sent: Monday, October 10, 2016 4:42 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I still do not agree: A phone n umber may be technically incorrect but still functional. Consider these examples: 0049-1234-56789 +49-123456789 +49.0123456789 0049(0)123456789 and variations thereof. All of these numbers will be readily usabla for anyone with half a brain cell, yet each and every one of these numbers is inaccurate under wcurrent whois policies. For reference, this would be the "correct" number: +49.123456789 So what does this tell us? It tells me that on the march to accuracy, we will create more issues than we will solve. I have seen mail delivered to horribly spelled addresses, yet otoh, I have also seen time and again that mail sent to perfectly correct addresses was not delivered, because the postman could not find it (for example because the entrance to a building in one street actually was located around the corner in another street) and the mail was returned undelivered. Best, Volker Am 09.10.2016 um 19:09 schrieb Richard Leaning: Michele, I don't disagree with you. There will always be scenarios where common sense prevails. But if you want to phone me you will need the accurate number - not something that looks like my number. If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address. All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try. Cheers Dick Richard Leaning RIPE NCC External Relations (Sent by iPhone) On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight <michele@blacknight.com<mailto:michele@blacknight.com>> wrote: Dick Sorry, but that's absolutely untrue. So I agree with Greg. I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times. Yet the postal services in the various countries that I've lived in have been able to get the mail to me. There is a very big difference between "functional" and "accurate". As others have pointed out, it's often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you'll find 9 times out of 10 that the address form doesn't allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address. Our office address, for example, lists us as being in Carlow. If you actually looked at a map you'd see that we aren't in Carlow, but in Laois. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265, Ireland Company No.: 370845 From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Richard Leaning <rleaning@ripe.net<mailto:rleaning@ripe.net>> Date: Friday 7 October 2016 at 19:20 To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Thats Greg for articulating it so well. all i was going to say was - 'You can't contact someone if the contact information is inaccurate' So i can't see how you can split the two. Richard Leaning External Relations RIPE NCC _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- 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<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Hi Greg, I wish it were so, but at ICANN, both are the same. Incorrectly formatted whois is incorrect whois in the books of ICANN compliance. And yes, I agree, that the terminology should be changed and used as a basis for our discussions. Best, Volker Am 10.10.2016 um 18:51 schrieb Greg Aaron:
In the post below, Volker is talking about data FORMATTING, not ACCURACY. Formatting and accuracy are distinct concepts. They can have a relationship, but they are not one and the same. It is very important to understand the difference.
Formatting is the way in which something is arranged or set out. For example, do you format country name in the written-out form ("Canada"), or do you use the two-letter abbreviation ("CA")? Either way the data is accurate; you know the contact is in Canada.
The formatting of many registration data fields is specified in the EPP RFCs, which registries and registrars have been required to follow for years. For example, RFC5733 says registries and registrars must use certain standard conventions for timestamps, use email address syntax as per RFC5322, use two-character country codes per ISO standards, and must format contact telephone numbers a certain way derived from international standards.
The benefits of standardized data formatting are obvious, and RFCs are designed to bring those benefits to the Internet. In the case of EPP, registries and registrars can store and trade data easily and accurately. As the SSAC has noted, these standards make it easier for people and applications to understand and use registration data (SAC051).
The 2013 RAA requires that registrars validate that certain data fields are FORMATTED CORRECTLY as per the standards. In SAC058, the SSAC described it this way: "Syntactic Validation refers to the assessment of data with the intent to ensure that they satisfy specified syntactic constraints, conform to specified data standards, and are transformed and formatted properly for their intended use."
Validating that the data is ACCURATE -- that it's truthful, or that an address is deliverable, or is suitable for operational purposes, or however you want to say it -- is a different concept. Validation of accuracy has different procedures and can have different standards. For more about that, please see the sections about Operational Validation and Identity Validation in SAC058. https://www.icann.org/en/system/files/files/sac-058-en.pdf The 2013 contains an operational validation requirement.
Recommendation 1 from SAC058 was: “The SSAC recommends that the ICANN community should consider adopting the terminology outlined in this report in documents and discussions.” The RDS WG should discuss that.
We have protocol standards so that things will work, and RFCs should be adhered to. Hopefully that is uncontroversial.
With best wishes,
--Greg
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Volker Greimann *Sent:* Monday, October 10, 2016 4:42 AM *To:* gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I still do not agree: A phone n umber may be technically incorrect but still functional.
Consider these examples:
0049-1234-56789 +49-123456789 +49.0123456789 0049(0)123456789
and variations thereof.
All of these numbers will be readily usabla for anyone with half a brain cell, yet each and every one of these numbers is inaccurate under wcurrent whois policies. For reference, this would be the "correct" number:
+49.123456789
So what does this tell us? It tells me that on the march to accuracy, we will create more issues than we will solve.
I have seen mail delivered to horribly spelled addresses, yet otoh, I have also seen time and again that mail sent to perfectly correct addresses was not delivered, because the postman could not find it (for example because the entrance to a building in one street actually was located around the corner in another street) and the mail was returned undelivered.
Best,
Volker
Am 09.10.2016 um 19:09 schrieb Richard Leaning:
Michele,
I don't disagree with you. There will always be scenarios where common sense prevails.
But if you want to phone me you will need the accurate number - not something that looks like my number.
If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address.
All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try.
Cheers
Dick
Richard Leaning
RIPE NCC
External Relations
(Sent by iPhone)
On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight <michele@blacknight.com <mailto:michele@blacknight.com>> wrote:
Dick
Sorry, but that’s absolutely untrue. So I agree with Greg.
I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times.
Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me.
There is a very big difference between “functional” and “accurate”.
As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address.
Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,
Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Richard Leaning <rleaning@ripe.net <mailto:rleaning@ripe.net>> *Date: *Friday 7 October 2016 at 19:20 *To: *Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning
External Relations
RIPE NCC
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- 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 <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
-- 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.
No, Compliance is more precise than that. In its breach letters, Compliance cites a "failure to validate [and/or verify] Whois contact information" and a specific paragraph or paragraphs of the RAA. Because formatting violations and verification violations (which address accuracy) -- are different things, covred by different contract provisions, and they are delivered differently. From: Volker Greimann [mailto:vgreimann@key-systems.net] Sent: Tuesday, October 11, 2016 4:48 AM To: Greg Aaron <gca@icginc.com>; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Hi Greg, I wish it were so, but at ICANN, both are the same. Incorrectly formatted whois is incorrect whois in the books of ICANN compliance. And yes, I agree, that the terminology should be changed and used as a basis for our discussions. Best, Volker Am 10.10.2016 um 18:51 schrieb Greg Aaron: In the post below, Volker is talking about data FORMATTING, not ACCURACY. Formatting and accuracy are distinct concepts. They can have a relationship, but they are not one and the same. It is very important to understand the difference. Formatting is the way in which something is arranged or set out. For example, do you format country name in the written-out form ("Canada"), or do you use the two-letter abbreviation ("CA")? Either way the data is accurate; you know the contact is in Canada. The formatting of many registration data fields is specified in the EPP RFCs, which registries and registrars have been required to follow for years. For example, RFC5733 says registries and registrars must use certain standard conventions for timestamps, use email address syntax as per RFC5322, use two-character country codes per ISO standards, and must format contact telephone numbers a certain way derived from international standards. The benefits of standardized data formatting are obvious, and RFCs are designed to bring those benefits to the Internet. In the case of EPP, registries and registrars can store and trade data easily and accurately. As the SSAC has noted, these standards make it easier for people and applications to understand and use registration data (SAC051). The 2013 RAA requires that registrars validate that certain data fields are FORMATTED CORRECTLY as per the standards. In SAC058, the SSAC described it this way: "Syntactic Validation refers to the assessment of data with the intent to ensure that they satisfy specified syntactic constraints, conform to specified data standards, and are transformed and formatted properly for their intended use." Validating that the data is ACCURATE -- that it's truthful, or that an address is deliverable, or is suitable for operational purposes, or however you want to say it -- is a different concept. Validation of accuracy has different procedures and can have different standards. For more about that, please see the sections about Operational Validation and Identity Validation in SAC058. https://www.icann.org/en/system/files/files/sac-058-en.pdf The 2013 contains an operational validation requirement. Recommendation 1 from SAC058 was: "The SSAC recommends that the ICANN community should consider adopting the terminology outlined in this report in documents and discussions." The RDS WG should discuss that. We have protocol standards so that things will work, and RFCs should be adhered to. Hopefully that is uncontroversial. With best wishes, --Greg 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 Volker Greimann Sent: Monday, October 10, 2016 4:42 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I still do not agree: A phone n umber may be technically incorrect but still functional. Consider these examples: 0049-1234-56789 +49-123456789 +49.0123456789 0049(0)123456789 and variations thereof. All of these numbers will be readily usabla for anyone with half a brain cell, yet each and every one of these numbers is inaccurate under wcurrent whois policies. For reference, this would be the "correct" number: +49.123456789 So what does this tell us? It tells me that on the march to accuracy, we will create more issues than we will solve. I have seen mail delivered to horribly spelled addresses, yet otoh, I have also seen time and again that mail sent to perfectly correct addresses was not delivered, because the postman could not find it (for example because the entrance to a building in one street actually was located around the corner in another street) and the mail was returned undelivered. Best, Volker Am 09.10.2016 um 19:09 schrieb Richard Leaning: Michele, I don't disagree with you. There will always be scenarios where common sense prevails. But if you want to phone me you will need the accurate number - not something that looks like my number. If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address. All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try. Cheers Dick Richard Leaning RIPE NCC External Relations (Sent by iPhone) On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight <michele@blacknight.com<mailto:michele@blacknight.com>> wrote: Dick Sorry, but that's absolutely untrue. So I agree with Greg. I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times. Yet the postal services in the various countries that I've lived in have been able to get the mail to me. There is a very big difference between "functional" and "accurate". As others have pointed out, it's often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you'll find 9 times out of 10 that the address form doesn't allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address. Our office address, for example, lists us as being in Carlow. If you actually looked at a map you'd see that we aren't in Carlow, but in Laois. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265, Ireland Company No.: 370845 From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Richard Leaning <rleaning@ripe.net<mailto:rleaning@ripe.net>> Date: Friday 7 October 2016 at 19:20 To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Thats Greg for articulating it so well. all i was going to say was - 'You can't contact someone if the contact information is inaccurate' So i can't see how you can split the two. Richard Leaning External Relations RIPE NCC _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- 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<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. -- 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<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Well, I keep seeing incorrect whois complaint from ARS regarding formatting errors. Best, Volker Am 11.10.2016 um 16:08 schrieb Greg Aaron:
No, Compliance is more precise than that. In its breach letters, Compliance cites a “failure to validate [and/or verify] Whois contact information“ and a specific paragraph or paragraphs of the RAA. Because formatting violations and verification violations (which address accuracy) -- are different things, covred by different contract provisions, and they are delivered differently.
*From:*Volker Greimann [mailto:vgreimann@key-systems.net] *Sent:* Tuesday, October 11, 2016 4:48 AM *To:* Greg Aaron <gca@icginc.com>; gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Hi Greg,
I wish it were so, but at ICANN, both are the same. Incorrectly formatted whois is incorrect whois in the books of ICANN compliance.
And yes, I agree, that the terminology should be changed and used as a basis for our discussions.
Best,
Volker
Am 10.10.2016 um 18:51 schrieb Greg Aaron:
In the post below, Volker is talking about data FORMATTING, not ACCURACY. Formatting and accuracy are distinct concepts. They can have a relationship, but they are not one and the same. It is very important to understand the difference.
Formatting is the way in which something is arranged or set out. For example, do you format country name in the written-out form ("Canada"), or do you use the two-letter abbreviation ("CA")? Either way the data is accurate; you know the contact is in Canada.
The formatting of many registration data fields is specified in the EPP RFCs, which registries and registrars have been required to follow for years. For example, RFC5733 says registries and registrars must use certain standard conventions for timestamps, use email address syntax as per RFC5322, use two-character country codes per ISO standards, and must format contact telephone numbers a certain way derived from international standards.
The benefits of standardized data formatting are obvious, and RFCs are designed to bring those benefits to the Internet. In the case of EPP, registries and registrars can store and trade data easily and accurately. As the SSAC has noted, these standards make it easier for people and applications to understand and use registration data (SAC051).
The 2013 RAA requires that registrars validate that certain data fields are FORMATTED CORRECTLY as per the standards. In SAC058, the SSAC described it this way: "Syntactic Validation refers to the assessment of data with the intent to ensure that they satisfy specified syntactic constraints, conform to specified data standards, and are transformed and formatted properly for their intended use."
Validating that the data is ACCURATE -- that it's truthful, or that an address is deliverable, or is suitable for operational purposes, or however you want to say it -- is a different concept. Validation of accuracy has different procedures and can have different standards. For more about that, please see the sections about Operational Validation and Identity Validation in SAC058. https://www.icann.org/en/system/files/files/sac-058-en.pdf The 2013 contains an operational validation requirement.
Recommendation 1 from SAC058 was: “The SSAC recommends that the ICANN community should consider adopting the terminology outlined in this report in documents and discussions.” The RDS WG should discuss that.
We have protocol standards so that things will work, and RFCs should be adhered to. Hopefully that is uncontroversial.
With best wishes,
--Greg
*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 *Volker Greimann *Sent:* Monday, October 10, 2016 4:42 AM *To:* gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
I still do not agree: A phone n umber may be technically incorrect but still functional.
Consider these examples:
0049-1234-56789 +49-123456789 +49.0123456789 0049(0)123456789
and variations thereof.
All of these numbers will be readily usabla for anyone with half a brain cell, yet each and every one of these numbers is inaccurate under wcurrent whois policies. For reference, this would be the "correct" number:
+49.123456789
So what does this tell us? It tells me that on the march to accuracy, we will create more issues than we will solve.
I have seen mail delivered to horribly spelled addresses, yet otoh, I have also seen time and again that mail sent to perfectly correct addresses was not delivered, because the postman could not find it (for example because the entrance to a building in one street actually was located around the corner in another street) and the mail was returned undelivered.
Best,
Volker
Am 09.10.2016 um 19:09 schrieb Richard Leaning:
Michele,
I don't disagree with you. There will always be scenarios where common sense prevails.
But if you want to phone me you will need the accurate number - not something that looks like my number.
If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address.
All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try.
Cheers
Dick
Richard Leaning
RIPE NCC
External Relations
(Sent by iPhone)
On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight <michele@blacknight.com <mailto:michele@blacknight.com>> wrote:
Dick
Sorry, but that’s absolutely untrue. So I agree with Greg.
I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times.
Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me.
There is a very big difference between “functional” and “accurate”.
As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address.
Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,
Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Richard Leaning <rleaning@ripe.net <mailto:rleaning@ripe.net>> *Date: *Friday 7 October 2016 at 19:20 *To: *Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning
External Relations
RIPE NCC
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
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 <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
-- 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 <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Hi, all- I do not think we should be talking of data as being accurate or inaccurate, but instead as being trusted. Data can be trusted if it satisfies the requirements of its intended use. Data cannot be trusted if it does not satisfy its intended uses. My view is that we should be considering this question at a later time, because the extent to which we can trust data depends as much on its intended use(s) (which we have not yet determined) as it does on the data itself. Best wishes, Ayden Férdeline [linkedin.com/in/ferdeline](http://www.linkedin.com/in/ferdeline) -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Local Time: 7 October 2016 5:21 PM UTC Time: 7 October 2016 16:21 From: gregshatanipc@gmail.com To: Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> gnso-rds-pdp-wg@icann.org <gnso-rds-pdp-wg@icann.org> It might be useful to bring in the findings of the WHOIS review team on this point. There have been multiple discussions of contactability and accuracy in various ICANN groups. We don't need to choose between "accuracy" and "contactability" to have this discussion. Quite the opposite. These are related concepts and our discussion needs to consider both concepts. Contactability can be correlated to "functional accuracy" and also to certain amount of "fault tolerance" in the data. Inaccuracy in some fields is highly detrimental to contactability, in others not so much. Sometimes a certain combination of inaccuracies is fatal to contactability. In other words, contactability informs the discussion of accuracy, and vice versa. Greg On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote: Indeed, I think we should talk about contactable, not "accurate". This was the result of similar discussions of the WHOIS review team, as I understand it, accuracy was defined as contactable. It makes sense to me. I realize that others want more data and more accuracy, but that is their goal, not necessarily the goal of this pdp. The goal of privacy advocates, or those who wish to see data protection law implemented (and I do realize we are few in number) is to minimize the collection of information to what is necessary. Stephanie On 2016-10-07 08:27, Michele Neylon - Blacknight wrote: Stephanie Here’s one we run into all the time: A lot of our clients in Northern Ireland do not view themselves as being part of the UK, so they’ll choose to list their country as “Ireland’. Is the data they supply “bad”? Strictly speaking yes Are they still reachable? Of course they are. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: [ http://mneylon.social](http://mneylon.social) Random Stuff: [ http://michele.irish](http://michele.irish) ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: [<gnso-rds-pdp-wg-bounces@icann.org>](mailto:gnso-rds-pdp-wg-bounces@icann.org) on behalf of Stephanie Perrin [<stephanie.perrin@mail.utoronto.ca>](mailto:stephanie.perrin@mail.utoronto.ca) Date: Friday 7 October 2016 at 00:42 To: Mark Svancarek [<marksv@microsoft.com>](mailto:marksv@microsoft.com), ["gnso-rds-pdp-wg@icann.org"](mailto:gnso-rds-pdp-wg@icann.org) [<gnso-rds-pdp-wg@icann.org>](mailto:gnso-rds-pdp-wg@icann.org) Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Not at all, ordinary people make mistakes all the time. However, rarely would this kind of mistake render the person/organization un-contactable, which it seems to me is the evil we are trying to avoid with bad data. On the other hand, criminals have a goal of being untraceable, so will continue to make sure they are not located, right? SP On 2016-10-06 19:20, Mark Svancarek wrote: There seems to be a presumption that bad data is caused entirely by bad people. Do we actually have data showing which fraction of bad data is created with criminal intent, and which fraction is just people being lazy or careless and then never being held accountable by the data actually being verified? [ ] From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, October 6, 2016 3:09 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I agree with those pushing back on including a commitment to accuracy in this statement of purpose. I think there are a number of sound reasons for this. Those of us who push back are not advocating for bad data, that would be silly. What we are addressing is the futility of attempting to get the criminal element to put good data in their registration data. If we force them, we drive ID theft. Here are a few of my reasons: 1. Governments actually do not usually invest taxpayers money verifying citizen data, they provide penalties for having inaccurate data and leave it at that. Verifying address and phone number, given the mobility of the population in the countries I am familiar with from my past government service (US, Canada, Australia, New Zealand, and UK) is expensive and there is very little way to enforce it. This being the case, why would we force ICANN to do this? The cost inevitably would fall on the Registrars and registries, and be passed on to the end users. 2. As mentioned above, any pressure to improve data quality can hardly be expected to get criminals to give their accurate data, it will drive them to steal good data. 3. The vast majority of people are actually honest. I do realize that there is a high volume of cybercrime, but penalizing the majority of end users for the actions of a few (even if those actions result in a high volume of phishing and malware etc) is not good policy. There are other ways to catch and dump bad domains. Prosecution of malfeasant registrants remains a problem, but frankly how many can be prosecuted across borders anyway? 4. We do have questions about accuracy that we need to address, according to our charter. The purpose of this purpose statement is to boil down our business requirements for the activity in which we are engaged. While many actors want more accurate data, how to get that accuracy is so open to question that I regard its inclusion in the statement of purpose as setting impossible goals. I would be happy to revise this sentence as follows: To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions Change to To enable release of gTLD registration data that may not otherwise be publicly available under specific conditions defined by policy, and to develop mechanisms to encourage greater accuracy of data. Stephanie Perrin On 2016-10-06 16:48, Chris Pelling wrote: Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris ------ From: "Nick Shorey" [<nick.shorey@culture.gov.uk>](mailto:nick.shorey@culture.gov.uk) To: "Volker Greimann" [<vgreimann@key-systems.net>](mailto:vgreimann@key-systems.net) Cc: "gnso-rds-pdp-wg" [<gnso-rds-pdp-wg@icann.org>](mailto:gnso-rds-pdp-wg@icann.org) Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: [ nick.shorey@culture.gov.uk](mailto:nick.shorey@culture.gov.uk) Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: [ www.linkedin.com/in/nicklinkedin](http://www.linkedin.com/in/nicklinkedin) On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net> wrote: Hi Greg, Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com> wrote: +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: [ 876-818-1799](tel:876-818-1799) Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net> wrote: Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Data Accuracy: What steps should be taken to improve data accuracy? Data Elements: What data should be collected, stored, and disclosed? Privacy: What steps are needed to protect data and privacy? Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? Compliance: What steps are needed to enforce these policies? System Model:What system requirements must be satisfied by any next-generation RDS implementation? Cost: What costs will be incurred and how must they be covered? Benefits: What benefits will be achieved and how will they be measured? Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, [ benny@nordreg.se](mailto:benny@nordreg.se) wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: [ +46.42197080](tel:%2B46.42197080) Direct: [+47.32260201](tel:%2B47.32260201) Mobile: [+47.40410200](tel:%2B47.40410200) From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Metalitz, Steven" <met@msk.com> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org>, Volker Greimann <vgreimann@key-systems.net>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should workto reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) · Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "[gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann](mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann)" <[gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net](mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net)> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to
as
"RDS") is to manage authorised parties' access to information about
[gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish
- "Current" would be more accurate (sic) / appropriate.
Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: [+49 (0) 6894 - 9396 901](tel:%2B49%20%280%29%206894%20-%209396%20901) Fax.: [+49 (0) 6894 - 9396 851](tel:%2B49%20%280%29%206894%20-%209396%20851) Email: vgreimann@key-systems.net Web: [www.key-systems.net](http://www.key-systems.net/) /[www.RRPproxy.net](http://www.rrpproxy.net/) [www.domaindiscount24.com](http://www.domaindiscount24.com/) /[www.BrandShelter.com](http://www.brandshelter.com/) Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP [www.keydrive.lu](http://www.keydrive.lu/) Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: [+49 (0) 6894 - 9396 901](tel:%2B49%20%280%29%206894%20-%209396%20901) Fax.: [+49 (0) 6894 - 9396 851](tel:%2B49%20%280%29%206894%20-%209396%20851) Email: vgreimann@key-systems.net Web: [www.key-systems.net](http://www.key-systems.net/) /[www.RRPproxy.net](http://www.rrpproxy.net/) [www.domaindiscount24.com](http://www.domaindiscount24.com/) /[www.BrandShelter.com](http://www.brandshelter.com/) Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP [www.keydrive.lu](http://www.keydrive.lu/) This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org 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 _______________________________________________ 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 _______________________________________________ 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](tel:%2B49%20%280%29%206894%20-%209396%20901) Fax.: [+49 (0) 6894 - 9396 851](tel:%2B49%20%280%29%206894%20-%209396%20851) 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](tel:%2B49%20%280%29%206894%20-%209396%20901) Fax.: [+49 (0) 6894 - 9396 851](tel:%2B49%20%280%29%206894%20-%209396%20851) 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 _______________________________________________ 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
As we struggle with what we want to mean about the adequate properties of data in this RDS work I would like to note, in passing, an article in another field, the connected car, that spends a considerable amount of time dealing with data issues. For what it is worth The following paper, dealing with open and closed software in automobiles, is an excellent read with regard to not only cars, but also a lot of privacy, security, proprietary, and regulatory issues with regard to data, some of which may yield useful insights or ideas with regard to domain name registration data issues. One may be with regard to data portability. Quote: As of May 2018, companies will be expressly required under the EU General Data Protection Regulation to consider data protection by design and by default, implement appropriate technical and organizational measures and enable data portability. [Council Directive 2016/670, 2016 O.J. (L 119) (EU)] “Open Cars”, Lothar Determann determan@uchastings.edu <mailto:determan@uchastings.edu> and Bruce Perens bruce@perens.com <mailto:bruce@perens.com> Legal Studies Research Paper Series, Research Paper No 213, University of California Hastings College of Law./ Draft 2016-7-4, last updated 9-20, 11 AM/
I am pretty sure that all registrars, or most of them at least, want to have as accurate data as possible! But to make that happen this must be based on public available info which can be checked. Deeper checks than that can in many cases not be done without costs and special authentications / permissions and then we can’t store the info and will never be allowed to push into RDS. The assumption, several people here advocate for, that because we don’t want the term accuracy as part of the policy make us wanting bad data in here are to say it nice childish. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200 From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Chris Pelling <chris@netearth.net> Date: Thursday, 6 October 2016 at 22:48 To: Nick Shorey <nick.shorey@culture.gov.uk> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Hi Nick, I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out. Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point. I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do. Registrant giving fake address = bad data Registrant giving correct address of neighbour = bad data Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked This list could be endless : Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data. I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work. Just a thought. Kind regards, Chris ________________________________ From: "Nick Shorey" <nick.shorey@culture.gov.uk> To: "Volker Greimann" <vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 6 October, 2016 17:38:55 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse... Nick Shorey BA(Hons) MSc. Senior Policy Advisor | Global Internet Governance Department for Culture, Media & Sport HM Government | United Kingdom Email: nick.shorey@culture.gov.uk<mailto:nick.shorey@culture.gov.uk> Tel: +44 (0)7710 025 626 Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin<http://www.linkedin.com/in/nicklinkedin> On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Greg, Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database. If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible. One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there. We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated. Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk.... Best, Volker On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com<mailto:carlton.samuels@gmail.com>> wrote: +1. Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799<tel:876-818-1799> Strategy, Planning, Governance, Assessment & Turnaround ============================= On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Folks Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it: First - background: Quoting the Charter on the Board decision to launch this PDP: On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy Later - what The Charter tasked this Working Group with: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: • Users/Purposes: Who should have access to gTLD registration data and why? • Gated Access: What steps should be taken to control data access for each user/purpose? • Data Accuracy: What steps should be taken to improve data accuracy? • Data Elements: What data should be collected, stored, and disclosed? • Privacy: What steps are needed to protect data and privacy? • Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system? •Compliance: What steps are needed to enforce these policies? • System Model:What system requirements must be satisfied by any next-generation RDS implementation? • Cost: What costs will be incurred and how must they be covered? • Benefits: What benefits will be achieved and how will they be measured? • Risks: What risks do stakeholders face and how will they be reconciled? So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work. So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table. Holly On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com<mailto:rrasmussen@infoblox.com>> wrote: Folks, Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem. Cheers, Rod On Oct 5, 2016, at 10:36 AM, benny@nordreg.se<mailto:benny@nordreg.se> wrote: But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080<tel:%2B46.42197080> Direct: +47.32260201<tel:%2B47.32260201> Mobile: +47.40410200<tel:%2B47.40410200> From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com<mailto:met@msk.com>> Date: Wednesday, 5 October 2016 at 19:32 To: 'Marika Konings' <marika.konings@icann.org<mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz 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 Marika Konings Sent: Wednesday, October 05, 2016 12:53 PM To: Volker Greimann; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw) includes the following question: As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions: (…..) • Data Accuracy: What steps should be taken to improve data accuracy? (……) Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net<mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/> www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901> Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851> Email: vgreimann@key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Agreed. Accuracy is not a purpose of the RDS, but it may be a way of achieving one ore more purposes. Accuracy is a means, not a goal in itself, hence my opinion that it should not included in the purpose document. Best, Volker Am 07.10.2016 um 08:11 schrieb benny@nordreg.se:
I am pretty sure that all registrars, or most of them at least, want to have as accurate data as possible! But to make that happen this must be based on public available info which can be checked. Deeper checks than that can in many cases not be done without costs and special authentications / permissions and then we can’t store the info and will never be allowed to push into RDS.
The assumption, several people here advocate for, that because we don’t want the term accuracy as part of the policy make us wanting bad data in here are to say it nice childish. __
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar
IANA-ID: 638
Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200
*From: *<gnso-rds-pdp-wg-bounces@icann.org> on behalf of Chris Pelling <chris@netearth.net> *Date: *Thursday, 6 October 2016 at 22:48 *To: *Nick Shorey <nick.shorey@culture.gov.uk> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Hi Nick,
I would actually concur with Volker. I see your point but, can I ask a question, the data collected cannot be proven to any certainty because we have nothing as the registry/registrar community to "check" it against. Simply checking say the address against a city, against a State, against a postal/zip code then country isnt proving the registrant data is correct, its simply proving that the registrant can open a phone book and pick an address out.
Until tools are created to prove that registrant is actually at address X, accuracy is a rather moot point.
I agree with your point about law enforcement and bad data being a cost to the public purse, but until the governments can get together and work out a solution for the data to be verified there is little anyone can do.
Registrant giving fake address = bad data
Registrant giving correct address of neighbour = bad data
Registrant giving old address where previously lived = bad data - but at least it could be validated against old correct data and cross checked
This list could be endless :
Registrant giving correct data = good, verifiable. Maybe the governments can work out a solution to being able to verify their citizens data.
I would love to find a solution that is workable and commercially viable, the governments and LEA can then use the data with some surety to its worthiness - although this is a totally separate topic, I would like to sit down and discuss it further - the governments getting together and helping this work.
Just a thought.
Kind regards,
Chris
------------------------------------------------------------------------
*From: *"Nick Shorey" <nick.shorey@culture.gov.uk> *To: *"Volker Greimann" <vgreimann@key-systems.net> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 6 October, 2016 17:38:55 *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Interesting comments Volker! I guess it's all about the perspective you view it from I suppose. The impact of bad data on law enforcement investigations can also be waste of valuable time and cost. Except the cost comes out of of the public purse...
*Nick Shorey BA(Hons) MSc.*
Senior Policy Advisor | Global Internet Governance
Department for Culture, Media & Sport
HM Government | United Kingdom
Email: nick.shorey@culture.gov.uk <mailto:nick.shorey@culture.gov.uk>
Tel: +44 (0)7710 025 626
Skype: nick.shorey
Twitter: @nickshorey
LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin>
On 6 October 2016 at 17:23, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Greg,
Arguments to the contrary tend to look like a Defense of Bad Data. I can't think of any reasons to defend bad data, unless one wants a bad database.
If you want reasons, here are a few: 1) Cost 2) Waste of valuable time 3) Implementation nightmares 4) No actual standard that applies worldwide 5) Legacy data from legacy sources 6) Customer service nightmare
It's reasonable to strive for perfectly accurate data, but accept that one will never get there. There should be commercially reasonable and proportionate methods to get as close as practically possible.
One can strive for anything, but it may never be achieved, consuming valuable ressources on the way. How many people died trying to reach the south pole, the north pole, the peak of the Matterhorn, before someone made it. While that first one to make is famous now, consider the loss of life and ressources wasted we spent getting there.
We have not (in this group) discussed data migration, but assuming a Garbage In, Garbage Out approach doesn't seem reasonable. Whether all the data is validated before migration, or just validated as part of a normal validation cycle, it needs be validated.
Existing data in is the only feasible solution if you want a manageable transition process. As for validation by the road, before designing a process we should define who is going to have to implement it, process it, deal with user complaints, pay for it, etc. What is better data worth to those who have to pay for it? Are those that benefit from better data going to finance it (including all associated costs)? If so, let's talk....
Best, Volker
On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels@gmail.com <mailto:carlton.samuels@gmail.com>> wrote:
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an RDS. If this PDP is tasked to build on the works of EWG maybe it'd be useful to re-visit certain ideas we now hold as verities.
-Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 <tel:876-818-1799> //Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote:
Folks
Maybe we need to back up a bit and go back to the Charter and what we are supposed to be doing. Let me quote directly from it:
First - background: Quoting the Charter on the Board decision to launch this PDP:
/On 26 May, 2015, the ICANN Board passed a resolution adopting that Process Framework and reaffirming its 2012 request for a Board - initiated PDP to define the purpose of collecting, maintaining and providing access to gTLD registration data, and to consider safeguards for protecting data, using the recommendations in the EWG’s Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy/
Later - what The Charter tasked this Working Group with:
/As part of its Phase 1 deliberations, the PDP WG should work to reach consensus recommendations by considering, at a minimum, the following complex and inter-related questions:/
/·// Users/Purposes: Who should have access to gTLD registration data and why?/
/·// Gated Access: What steps should be taken to control data access for each user/purpose?/
/·// Data Accuracy: What steps should be taken to improve data accuracy?/
/·// Data Elements: What data should be collected, stored, and disclosed?/
/·// Privacy: What steps are needed to protect data and privacy?/
/·// Coexistence: What steps should be taken to enable next-generation RDS coexistence with and replacement of the legacy WHOIS system?/
/·//Compliance: What steps are needed to enforce these policies?/
/·// System Model:What system requirements must be satisfied by any next-generation RDS implementation?/
/·// Cost: What costs will be incurred and how must they be covered?/
/·// Benefits: What benefits will be achieved and how will they be measured?/
/·// Risks: What risks do stakeholders face and how will they be reconciled?/
So accuracy’s there - along with a lot of other issues. That is not saying that accuracy is not covered in existing requirements on registries/registrars. But it is giving a broader meaning to RDS - i.e., it’s not just about collection, maintenance and access to data; it’s also about safeguards, etc - using the EWG work.
So thanks Rob. It’s a bit premature to rule issues out when they are well and truly on our table.
Holly
On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen@infoblox.com <mailto:rrasmussen@infoblox.com>> wrote:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data.
RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level.
WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything.
--
Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar
IANA-ID: 638
Phone: +46.42197080 <tel:%2B46.42197080> Direct: +47.32260201 <tel:%2B47.32260201> Mobile: +47.40410200 <tel:%2B47.40410200>
*From:*<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> *Date:*Wednesday, 5 October 2016 at 19:32 *To:*'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no
presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*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*Marika Konings *Sent:*Wednesday, October 05, 2016 12:53 PM *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (seehttps://community.icann.org/x/E4xlAw) includes the following question:
**
*/AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach consensusrecommendations byconsidering,*ataminimum*, thefollowingcomplexandinter-related questions:/
/(…..)/
·*/Data Accuracy:/**//*/Whatstepsshould betakentoimprovedataaccuracy?/
/(……)/
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> gnso-rds-pdp-wg mailing list
>gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/>
www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu/>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> / www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
Fax.: +49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> / www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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.
Hi Rod, some of this sounds like a very bad idea. Please remember that besides the regulated world of gTLDs there also exists the colorful world of ccTLDs and contacts are shared between registrations in both at many registrars. Once you start enforcing purpose based contacts that are changed as you describe, you may also trigger unwanted and unannounced charges for the registrant when his contact details are updated on contacts also used in ccTLDs where such changes carry a fee. Best, Volker Am 05.10.2016 um 21:37 schrieb Rod Rasmussen:
Folks,
Gotta chime in here, since the EWG provided a lot of thinking on this issue. If you haven’t already, please review the EWG report sections on data accuracy and also the concept of data validators and their relationship to the RDS. For example, I would note that a well-provisioned RDS would be able to provide some sort of validation checks against existing data in the use case of trying to prevent impersonation (a form of accuracy) of an existing registrant (a big brand like Facebook for instance). Another concept we found very important in the EWG is the idea of creating a contact data set tied to a contact ID that is portable between registrars and registries. This provides for the purpose-based contacts we talk about at great length in the report. It also is key for addressing some of the fundamental operational issues that lead to inaccurate, out-of-date data at various registrars. If you have a change in your contact information (a new e-mail for instance) and hold multiple roles in conjunction with many domains, you have a real challenge making updates throughout the universe of your domain names. Using a data validator and then acting via the RDS, when you make a change to your contact info, that automatically can be reflected in all domains you are associated with and thus improve accuracy tremendously. Those are just a couple examples of how an RDS can be involved in dealing with accuracy issues and represent many of the concepts you can address once you look beyond the current paradigm of registrar controlled contact information anchored specifically to individual domain names. Accuracy in the “generic” system (including registries, registrars, RDS, validators, some other group we haven’t thought of yet) is definitely in-scope. How that is done can take many forms and could have different roles played by different participants in the entire ecosystem.
Cheers,
Rod
On Oct 5, 2016, at 10:36 AM, benny@nordreg.se <mailto:benny@nordreg.se> wrote:
But the data accuracy can’t be done in RDS, the accuracy is done on a registrar level when collecting data. RDS shall under no circumstances alter any information received from registry / registrars and showing any different info than what is collected on that level. WG can look at what accuracy they want registrars to do yes, but RDS doesn’t do anything. -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
Benny Samuelsen Registry Manager - Domainexpert
Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.42197080 Direct: +47.32260201 Mobile: +47.40410200 *From:*<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Metalitz, Steven" <met@msk.com <mailto:met@msk.com>> *Date:*Wednesday, 5 October 2016 at 19:32 *To:*'Marika Konings' <marika.konings@icann.org <mailto:marika.konings@icann.org>>, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>>, "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no presumption of any prior cleanup work”? That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates. Steve Metalitz *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*Marika Konings *Sent:*Wednesday, October 05, 2016 12:53 PM *To:*Volker Greimann; gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> *Subject:*Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Volker, please note that the PDP WG Charter (seehttps://community.icann.org/x/E4xlAw) includes the following question: ** */AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach consensusrecommendations byconsidering,*ataminimum*, thefollowingcomplexandinter-related questions:/ /(…..)/ ·*/Data Accuracy:/**//*/Whatstepsshould betakentoimprovedataaccuracy?/ /(……)/ Best regards, Marika On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote: I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker >> THE purpose of the "Registration Data Service" (hereafter referred to >> as >> "RDS") is to manage authorised parties' access to information about >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD >> Registrars] >> >> Purpose 3(a/b) are possible use cases, not Purposes as such >> >> "Accurate" is definitely not a term to use if we ever expect to finish >> - "Current" would be more accurate (sic) / appropriate. > Agreed, with one minor suggestion: > > "access to information about generic top-level domain registries, registrars, names, and name servers." > > Scott > _______________________________________________ > gnso-rds-pdp-wg mailing list >gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> >https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- 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 <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net> Web:www.key-systems.net <http://www.key-systems.net/>/www.RRPproxy.net <http://www.rrpproxy.net/> www.domaindiscount24.com <http://www.domaindiscount24.com/>/www.BrandShelter.com <http://www.brandshelter.com/> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu/> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- 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 agree that if all existing whois policy were to ultimately be replaced by the RDS, the existing provisions would have to be adopted or adapted. I also do not in general object to improvements of accuracy going forward. I do however note that any migration to the new system will include legacy data that may be outdated, incorrect or incomplete. Fixing the existing data may prove near impossible at worst and very expensive at best. Hence my assumption that existing data will have to be imported/presented as is, since no one will want to pay for this. Best, Volker Am 05.10.2016 um 19:32 schrieb Metalitz, Steven:
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no
presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Marika Konings *Sent:* Wednesday, October 05, 2016 12:53 PM *To:* Volker Greimann; gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw <https://community.icann.org/x/E4xlAw>) includes the following question:
**
*/Aspartof its Phase1 deliberations,/*/thePDP WG shouldwork toreach consensusrecommendations by considering,*at aminimum*, the followingcomplexandinter-related questions:/
/(…..)///
·*/Data Accuracy:/**//*/Whatstepsshould betakentoimprove data accuracy?/
/(……)/
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> / www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> / www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Additionally to my previous mail, the charter does not presuppose additional data accuracy. It asks what steps should be taken to improve data accuracy. The answer to this question could very well be the following: NONE! Therefore, presupposing anything definite about additional data accuracy at this point is premature at best, and bad faith at worst. Best, Volker Am 05.10.2016 um 19:32 schrieb Metalitz, Steven:
Volker, what is the basis for your assertion that “data will be presented "as is" in this system, with no
presumption of any prior cleanup work”?
That statement will be true if we ultimately conclude that the current system is adequate and that we do not recommend establishment of a new RDS. However, if we do recommend a new system, then improvements to data accuracy are very much on the table, as the charter provision quoted by Marika indicates.
Steve Metalitz
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Marika Konings *Sent:* Wednesday, October 05, 2016 12:53 PM *To:* Volker Greimann; gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker, please note that the PDP WG Charter (see https://community.icann.org/x/E4xlAw <https://community.icann.org/x/E4xlAw>) includes the following question:
**
*/Aspartof its Phase1 deliberations,/*/thePDP WG shouldwork toreach consensusrecommendations by considering,*at aminimum*, the followingcomplexandinter-related questions:/
/(…..)///
·*/Data Accuracy:/**//*/Whatstepsshould betakentoimprove data accuracy?/
/(……)/
Best regards,
Marika
On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann>" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net <mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net>> wrote:
I would move to strike all references to data quality altogether from
this document, e.g. "current", "accurate" etc.
These are already required by existing policies and agreements and do
not have to be referenced again at this point. We should focus on having
to reflect the data as provided by the RNH at this stage, not make any
presumptions about its quality.
After all, data will be presented "as is" in this system, with no
presumption of any prior cleanup work.
Best,
Volker
>> THE purpose of the "Registration Data Service" (hereafter referred to
>> as
>> "RDS") is to manage authorised parties' access to information about
>> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
>> Registrars]
>>
>> Purpose 3(a/b) are possible use cases, not Purposes as such
>>
>> "Accurate" is definitely not a term to use if we ever expect to finish
>> - "Current" would be more accurate (sic) / appropriate.
> Agreed, with one minor suggestion:
>
> "access to information about generic top-level domain registries, registrars, names, and name servers."
>
> Scott
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> / www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net <http://www.RRPproxy.net>
www.domaindiscount24.com <http://www.domaindiscount24.com> / www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Totally agree Volker. Kind regards, Chris From: "Volker Greimann" <vgreimann@key-systems.net> To: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 5 October, 2016 12:58:58 Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I would move to strike all references to data quality altogether from this document, e.g. "current", "accurate" etc. These are already required by existing policies and agreements and do not have to be referenced again at this point. We should focus on having to reflect the data as provided by the RNH at this stage, not make any presumptions about its quality. After all, data will be presented "as is" in this system, with no presumption of any prior cleanup work. Best, Volker
THE purpose of the "Registration Data Service" (hereafter referred to as "RDS") is to manage authorised parties' access to information about [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD Registrars]
Purpose 3(a/b) are possible use cases, not Purposes as such
"Accurate" is definitely not a term to use if we ever expect to finish - "Current" would be more accurate (sic) / appropriate. Agreed, with one minor suggestion:
"access to information about generic top-level domain registries, registrars, names, and name servers."
Scott _______________________________________________ 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
On Tue, Oct 04, 2016 at 09:53:14AM -0400, Stephanie Perrin wrote:
I would suggest that if you boil it down to this, you need to say " The Purpose of RDS is to */manage/* access to information about Domain Names,
I _almost_ object to this, because it's in fact the repository operator(s) who manage that access (i.e. who set the relevant operational and policies for a given user class), not the RDS. The RDS enforces those access policies, however. So perhaps to enforce access policies to information about registration data in a [g]TLD ? It need not be just info about domain names, name servers, or registrars, after all. (One example that leaps to mind is the possible variant relations among domain names, which under some interpretations might not be about "domain names" as such since some of the strings might _not_ be domain names for various technical reasons). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Chuck, Yes. The Purpose of RDS is to provide access to information about Domain Names, Name Servers and Registrars in a TLD. This statement is broad enough to encompass the other 4 proposed statements as well as other concepts. Thank you, Marc From: Gomes, Chuck Sent: Tuesday, October 04, 2016 9:41 AM To: Anderson, Marc; gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Marc, In your last suggestion, are you suggesting that all four purpose statements (1, 2, 3a and 3b) could be replaced with your suggested statement? 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 Anderson, Marc Sent: Thursday, September 29, 2016 12:38 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose I appreciate the concerns Chuck and others have raised that we are spending too much time on the RDS statement of purpose. I know many of us (myself included) are anxious to get to get to the requirements deliberation phase. That said it’s important that we do a proper job drafting the RDS statement of purpose. As a PDP we’ll be judged on the quality of our work and the statement of purpose will be a very visible output. Rushing through this will not serve us well in the long run With a goal of wrapping this up quickly and efficiently in mind, I’ll skip the intro and goals section and get right to the purpose section. Purpose 1: A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle) to enable management of a domain name registration. I agree that the first part of that statement “…provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle)” is a purpose of RDS. The second part however “to enable management of a domain name registration” does not belong in a purpose statement. This deals with a potential use case which I’m sure we’ll discuss in the requirements deliberation phase. I would suggest an updated purpose 1 read: “A purpose of gTLD registration data is to provide information about the lifecycle of a domain name (as specified by ICANN’s Diagram of gTLD Lifecycle).” Purpose 2: A purpose of a system to collect, maintain, and provide access to gTLD registration data (hereafter referred to as “the RDS”) is to provide information that is needed by authorized parties to operate a gTLD generic top-level domain name in the DNS. I have concerns with this second purpose statement. Purpose 2 provides a definition of RDS and one that I don’t feel is accurate. RDS does not collect or maintain gTLD registration data. It does provide access to that data, but as I said on the call the Registration system itself that registries make accessible to registrars via EPP is the system that collects and maintains gTLD registrations data. For purpose 2 how about: “A purpose of RDS is to provide information that is needed by authorized parities to operate a generic top-level domain name in the DNS”. Purpose 3: Further specific purposes of the RDS include: a. To enable contact with registrants, registrars, (registries?), and proxy/privacy service providers associated with gTLD domain names, for specific policy-defined purposes. b. To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions I’m not sure why this is broken into a 3a and 3b. They don’t appear related and should be purpose 3 and 4 respectively. RDS doesn’t include registry data, so only registrants, registrars and proxy/privacy providers apply. The “for specific policy-defined purposes” doesn’t belong in a RDS purpose statement, it’s more appropriate to the requirements deliberation phase. An updated Purpose 3 would read: “A purpose of RDS is to facilitate contact with registrants, registrars and proxy/privacy service providers associated with generic top-level domain names.” For 3b I don’t necessarily agreed with “accurate” in the purpose statement. Having accurate data may be a goal, but the purpose is to display the data of record. In fact a potential use case is to facilitate the correction of inaccurate data. The “under specific and explicit policy-defined conditions” again refers to a potential requirement of RDS but not a purpose. A new purpose 4 would read: “A purpose of RDS is to enable the release of gTLD registration data that may not otherwise be publicly available.” Looking at these 4 purposes I think there is a theme. You could say that they could all be rolled up in the statement “The purpose of RDS is to provide access to information about domain names in a TLD.” As Whois today also provides information about Registrars and Name Servers, perhaps a more fulsome consolidated RDS purpose statement could be: The Purpose of RDS is to provide access to information about Domain Names, Name Servers and Registrars in a TLD. Thank you, Marc Anderson 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 Marika Konings Sent: Wednesday, September 28, 2016 1:12 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Dear All, Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>.
Dear all: Three topic for consideration below. One: The doc says that one of the “Overall Goals for this Statement of Purpose” is “To set unambiguous boundaries for RDS policy requirements and RDS consensus policies.” That is too broad. The doc is setting some minimum criteria about purpose, but that is very different from setting all the boundaries. The WG’s Charter ultimately sets the boundaries we are working within. And the current doc is not “unambiguous.” I don’t think this sentence is very helpful, and should be deleted. If the purpose is to provide guidance and focus this segment of the WG’s work, then let’s create a sentence that better captures the scope. Two: Purpose 3b says: “To enable release of accurate gTLD registration data that may not otherwise be publicly available, under specific and explicit policy-defined conditions.” This sentence is overloaded. a. This is the doc’s only mention of data accuracy, an important topic. The doc says that accuracy is a concern only in cases of gated or preferential access, but ICANN policy has always been to encourage data accuracy across the board. b. A purpose of an RDS may be to release registration data that IS publicly available in other ways. Current examples include domain and nameserver data found in zone files and the DNS, registrar contact info, etc. c. “under specific and explicit policy-defined conditions” is not just about release – it implies that all allowable usages can be defined, managed, and enforced. The WG is not into that part of the discussion yet, and it’s a complicated and controversial area. So I think the phrase is too open-ended. So I suggest an edit to read: “To enable release of gTLD registration data that may or may not otherwise be publicly available, where the released types of data are determined by policy-defined conditions.” Then data accuracy deserves its own item under “Specific Purposes”; inserting it into the existing items doesn’t work. I suggest we add: “A purpose of a system to collect, maintain, and provide access to gTLD registration data (hereafter referred to as “the RDS”) is to collect and provide information that is accurate.” I think that meets all of the doc’s stated Goals. Three: Mark Anderson made some good comments. · As Marc says, 3a and 3b are set apart as less important than 1 and 2 for some reason. As Marc suggests, just number the existing purposes 1 through 4. The statement about accuracy would add a fifth. · Marc suggests Purpose 3 to read: “A purpose of RDS is to facilitate contact with registrants, registrars and proxy/privacy service providers associated with generic top-level domain names.” I suggest updating that to read: “A purpose of RDS is to identify and facilitate contact with domain contacts, registrars, and proxy/privacy service providers associated with generic top-level domain names.” “Registrants” does not cover other contact types. An original purpose of the current system was to facilitate contact with admin and tech contacts. And identifying is a different task and involves different use cases than contacting. A RDS can inform, but does not require the user to contact everyone he or she looks up. All best, --Greg From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Marika Konings Sent: Wednesday, September 28, 2016 1:12 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose Dear All, Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>.
Hi, This is not really a fatal objection, and I can accept the inclusion since people seem to think it important (and because ultimately it's our charter that limits our freedom of action), but I continue to wonder why we keep including "collect" in the description of the RDS ("RDS, i.e., the system that may collect, maintain, and provide or deny access to some or all of those data elements [and services related to them, if any]"). The RDS _does not_ collect the data. That is the responsibility of the SRSes underlying registrations. I recall spending some time making diagrams illustrating this some months ago (it was before I moved back to Toronto, so it was before the end of June, but I don't recall when exactly). The RDS provides _access_ to that registration data. The RDS policies might have implications for registration policies (i.e. what data must be collected), but I cannot see how expanding our scope to talk about what registration _may_ collect is helpful. And we keep tripping over this because people point to consensus policies sometimes that are in fact about registration and not publication of the data. I therefore think that item 2 under "specific purpose" is actually false: that's the purpose of the SRS, and _not_ the RDS. The RDS is for lookup, and we should concentrate on that. Nit under "Goals": item iv is poor parallel construction. It could be fixed with "To help articilate [clearly, if you want] …" Best regards, A On Wed, Sep 28, 2016 at 05:12:29PM +0000, Marika Konings wrote:
Dear All,
Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated.
Best regards,
Marika
Marika Konings
Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)
Email: marika.konings@icann.org
Follow the GNSO via Twitter @ICANN_GNSO
Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, it may not collect the data directly from the registrant, but it does collect the data from registries, who collect it from registrars. Ultimately, the collection must have a legitimate purpose. "Because we want the data to be public" is not a legitimate purpose. Best, Volker Am 04.10.2016 um 17:31 schrieb Andrew Sullivan:
Hi,
This is not really a fatal objection, and I can accept the inclusion since people seem to think it important (and because ultimately it's our charter that limits our freedom of action), but I continue to wonder why we keep including "collect" in the description of the RDS ("RDS, i.e., the system that may collect, maintain, and provide or deny access to some or all of those data elements [and services related to them, if any]").
The RDS _does not_ collect the data. That is the responsibility of the SRSes underlying registrations. I recall spending some time making diagrams illustrating this some months ago (it was before I moved back to Toronto, so it was before the end of June, but I don't recall when exactly). The RDS provides _access_ to that registration data.
The RDS policies might have implications for registration policies (i.e. what data must be collected), but I cannot see how expanding our scope to talk about what registration _may_ collect is helpful. And we keep tripping over this because people point to consensus policies sometimes that are in fact about registration and not publication of the data.
I therefore think that item 2 under "specific purpose" is actually false: that's the purpose of the SRS, and _not_ the RDS. The RDS is for lookup, and we should concentrate on that.
Nit under "Goals": item iv is poor parallel construction. It could be fixed with "To help articilate [clearly, if you want] …"
Best regards,
A
On Wed, Sep 28, 2016 at 05:12:29PM +0000, Marika Konings wrote:
Dear All,
Please find attached for your review the updated statement of purpose which aims to reflect the changes discussed during yesterday’s meeting. You are all encouraged to review this version, especially the section ‘Specific Purposes for Registration Data and Registration Directory Services’, and share your input with the mailing list prior to next week’s meeting. Also note that a couple of WG members (Marc & Fabrizio) volunteered to provide updated language for two specific parts of the document which have been flagged accordingly, so please hold your comments on those parts until the proposed language has been circulated.
Best regards,
Marika
Marika Konings
Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)
Email: marika.konings@icann.org
Follow the GNSO via Twitter @ICANN_GNSO
Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.
_______________________________________________ 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.
participants (28)
-
Alan Greenberg -
Anderson, Marc -
Andrew Sullivan -
Ayden Férdeline -
benny＠nordreg.se -
Carlton Samuels -
Chris Pelling -
Gomes, Chuck -
Greg Aaron -
Greg Shatan -
gtheo -
Hollenbeck, Scott -
Holly Raiche -
Marika Konings -
Marina Lewis -
Mark Svancarek -
Metalitz, Steven -
Michele Neylon - Blacknight -
Nick Shorey -
Richard Leaning -
Richard Padilla -
Rob Golding -
Rod Rasmussen -
Sam Lanfranco -
Stephanie Perrin -
theo geurts
-
Victoria Sheckler -
Volker Greimann