a suggestion for "purpose in detail"
Hi, I left the meeting with data protection experts last week feeling quite strongly the need for a specific and concrete purpose for each datum we recommend to collect and to make available; and the need for a definition of who the maximal (appropriate) audience is (given the purpose). At the same time, I think that a reasonably short and high-level statement of purpose along the lines that we have been preparing can provide a useful set of principles. It strikes me that maybe we could take the high-level purpose statement, and go through some potential data elements and link each one concretely to at least one of the principles in our candidate list. In what follows I name these "purpose 1", "purpose 2", &c. The purposes are numbered according to the scheme in RDS PDP Phase 1: Key Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware that the details in the candidate list are still in flux, but I think the broad strokes are pretty close anyway, so I thought I'd try it with the "thin" data we agreed to start with. This mail is a little long because I'm dealing with all the classes of elements in one message. I suppose we could break this into one-thread-per-element (or class) if we don't converge quickly on each of them. The outline below is just my view, of course, though obviously I think that what I say is true. I use the "maximal audience" because I think that if there is any "whole public" use then there's no point considering more restrictive uses. (For instance, if we need the domain name to be published to everyone on the Internet because it won't work otherwise, then it makes no difference if LEOs want that data under some sort of authorized-access protocol, because they'll just get it under the wide-open rules instead. So we don't need to care about the LEO purpose in that case.) "Maximal audience" might not work for cases where two different classes have different needs both of which require some restrictions, but it's handy here because we're talking about thin data. I'm sorry this is long, but I hope it is a useful contribution to the discussion. Best regards, A ---%<---cut here--- Here is a convenient example thin whois response, in case anyone wants it to for reference in what follows. (Among other things, it reminds me that something I started to do has never been completed, so thank you to this WG for reminding me of that. :-) ) Domain Name: ANVILWALRUSDEN.COM Registrar: TUCOWS DOMAINS INC. Sponsoring Registrar IANA ID: 69 Whois Server: whois.tucows.com Referral URL: http://www.tucowsdomains.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Updated Date: 17-jan-2017 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017 1. DOMAIN NAME --------------- a. Collection The domain name is required to be collected under purpose 1. Without this, there is no domain name, so it is literally impossible to have anything to collect or publish. b. Publication The domain name is required to be published under purpose 1, because it is a key by which data is accessed. If you wish to look up the current data about a particular name, you use the name as the key by which you query. (This is not the only possible key. For instance, in an EPP registry you could in principle use the ROID to look up a particular name object. But that does not give you the current data for the thing so named; it just gives you the data about that Repository Object. Two different versions of the same name -- like if example.com is registered by Alice then deleted and later registered by Bob -- have different ROIDs.) c. Maximal audience The data audience is Internet-wide under purpose 1 or purpose 2 (or both). The domain name is by definition not private data, because domain names registered in DNS domain name registries (i.e. every registry possibly covered by ICANN policy -- the registries subordinate to the IANA DNS name registries) are name registration in a public name space. Note that it is not possible to keep the existence of a name private, because even if a name were initially undisclosed its existence would be disclosed whenever someone else tried to register it. 2. REGISTRAR IDENTITY ------------------- There are four items here, but three classes of data. The (i) registrar ID provides data about the entity that created the entry in the registry (formally, in EPP, "repository"). The (ii) Whois Server and Referral URL both provide metadata necessary for the operation of the distributed database that makes up the RDS (in systems other than whois, approximately the same data with the same relation to identity would be in place, but the details might be different. I think we can treat this as a class anyway). Finally, IANA has a registry of registrar IDs (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), and that contains their (iii) names. This is a protocol parameter registry, but it appears to be managed by ICANN so it is probably appropriate for this PDP to make the policy about how that is to be managed. a. Collection Data (i) and (ii) are all required to be collected under purposes 1 and 2. Without this data it is not possible to know the source of the data and it is not possible to trace it further in the system. Data (iii) needs to be collected in order to give (i) meaning, because it is the only way to know whether two IANA ids are bound to the same organization or person. b. Publication Data (i) are possibly required to be published under purpose 1. This largely depends on whether we think the identity of who is managing an object in the registry is part of the "lifecycle of a domain name". My feeling is "yes". Also, this information is likely to be disclosed anyway; see below. Data (ii) are required to be published under purposes 1 and 2, as long as there is at least one data element that is required under some purpose and is not available from the registry. (Since the actual registration life cycle is controlled by the registrar and not the registry, this appears likely.) Owing to the way these work, publication of these is likely to "leak" information about (i) or (iii) also. c. Maximal audience Given purposes 2 and 3 and probably 5, and since the source of contact information is registrars, the maximal audience is probably everyone on the Internet. If we think that purposes 2, 3, or 5 are limited in respect of who needs to make such contact or who needs to check accuracy, then the maximal audience is the set of all those who have such a need. It's worth observing, however, that at least the technical contact for a name ought to be contactable by anyone on the Internet, since when we want to "facilitate communication with domain contacts" at least part of the reason is as a fallback when a site breaks in some way. (This may suggest that we need to unpack the details of purpose 3.) 3. NAME SERVERS --------------- a. Collection Without collecting the name servers, domain names cannot function on the Internet, so this is required under purposes 1 and 2. (Given that the registration of the name itself and the collection of the name servers are both required for the basic functioning of the Internet Domain Name System, it strikes me that we may be missing a more obvious purpose in our list, but I guess (1) and (2) will be enough and we're already so late that I am loathe to suggest something more.) b. Publication Whenever a name is available on the Internet, the name server data is already available in the DNS, so this data is necessarily published. Under either purpose 1 or 2 (or both), the data about nameservers in the RDS provides an avenue for troubleshooting issues in the DNS, and so it is required for those purposes. c. Maximal audience Anyone who wants to access a site must be able to find this data in the DNS. Potentially anyone who has a problem with resolution can use the data in the RDS to aid in troubleshooting, so the audience under purpose 1 or 2 (or both) is everyone on the Internet. 4. STATUS VALUES ---------------- a. Collection The status values are not exactly "collected", but are at least in part the result of various actions by the sponsoring registrar and registry on the name. (Some can be set directly.) These govern the disposition of the name in question, and are a necessary condition for having a shared registration system, so they are required under purpose 1. b. Publication The status values govern the possible things that could be done to a name, and therefore the data must be published under purpose 1. c. Maximal audience At leasr some status values are required for doing some troubleshooting of resolution failures, so the audience for at least some values under purposes 1 or 2 is "everyone on the Internet". It is possible to argue that some of the status values are relevant only to those people who wish to perform some actions on the domain (such as transferring) or people in a position to do some kinds of activity (such as updating contact information). If we really think it necessary, we could undertake the exercise of audience evaluation for each EPP status. 5. DATES --------- While the dates might appear to be different kinds, they aren't, since for our purposes they all have at least one common utility (see below). a. Collection The dates, like status values, are not exactly "collected": they're a consequence of certain activities. They're necessary for the workings of the shared registration systems using the current fee-for-term model that (approximately?) all gTLD registries use today, so they're required under purpose 1. b. Publication The dates are required under purpose 1 or 2 in order to aid troubleshooting of resolution. (If a name worked yesterday and not today, it is helpful to know that it was just created -- meaning the old one was deleted -- or that it is expired, or that someone updated the name only last night.) c. Maximal audience Because of the troubleshooting aspects of these dates, the audience under purpose 1 or 2 is everyone on the Internet. -- Andrew Sullivan ajs@anvilwalrusden.com
+1 Nathalie On Monday, March 20, 2017 7:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: Hi, I left the meeting with data protection experts last week feeling quite strongly the need for a specific and concrete purpose for each datum we recommend to collect and to make available; and the need for a definition of who the maximal (appropriate) audience is (given the purpose). At the same time, I think that a reasonably short and high-level statement of purpose along the lines that we have been preparing can provide a useful set of principles. It strikes me that maybe we could take the high-level purpose statement, and go through some potential data elements and link each one concretely to at least one of the principles in our candidate list. In what follows I name these "purpose 1", "purpose 2", &c. The purposes are numbered according to the scheme in RDS PDP Phase 1: Key Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware that the details in the candidate list are still in flux, but I think the broad strokes are pretty close anyway, so I thought I'd try it with the "thin" data we agreed to start with. This mail is a little long because I'm dealing with all the classes of elements in one message. I suppose we could break this into one-thread-per-element (or class) if we don't converge quickly on each of them. The outline below is just my view, of course, though obviously I think that what I say is true. I use the "maximal audience" because I think that if there is any "whole public" use then there's no point considering more restrictive uses. (For instance, if we need the domain name to be published to everyone on the Internet because it won't work otherwise, then it makes no difference if LEOs want that data under some sort of authorized-access protocol, because they'll just get it under the wide-open rules instead. So we don't need to care about the LEO purpose in that case.) "Maximal audience" might not work for cases where two different classes have different needs both of which require some restrictions, but it's handy here because we're talking about thin data. I'm sorry this is long, but I hope it is a useful contribution to the discussion. Best regards, A ---%<---cut here--- Here is a convenient example thin whois response, in case anyone wants it to for reference in what follows. (Among other things, it reminds me that something I started to do has never been completed, so thank you to this WG for reminding me of that. :-) ) Domain Name: ANVILWALRUSDEN.COM Registrar: TUCOWS DOMAINS INC. Sponsoring Registrar IANA ID: 69 Whois Server: whois.tucows.com Referral URL: http://www.tucowsdomains.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Updated Date: 17-jan-2017 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017 1. DOMAIN NAME --------------- a. Collection The domain name is required to be collected under purpose 1. Without this, there is no domain name, so it is literally impossible to have anything to collect or publish. b. Publication The domain name is required to be published under purpose 1, because it is a key by which data is accessed. If you wish to look up the current data about a particular name, you use the name as the key by which you query. (This is not the only possible key. For instance, in an EPP registry you could in principle use the ROID to look up a particular name object. But that does not give you the current data for the thing so named; it just gives you the data about that Repository Object. Two different versions of the same name -- like if example.com is registered by Alice then deleted and later registered by Bob -- have different ROIDs.) c. Maximal audience The data audience is Internet-wide under purpose 1 or purpose 2 (or both). The domain name is by definition not private data, because domain names registered in DNS domain name registries (i.e. every registry possibly covered by ICANN policy -- the registries subordinate to the IANA DNS name registries) are name registration in a public name space. Note that it is not possible to keep the existence of a name private, because even if a name were initially undisclosed its existence would be disclosed whenever someone else tried to register it. 2. REGISTRAR IDENTITY ------------------- There are four items here, but three classes of data. The (i) registrar ID provides data about the entity that created the entry in the registry (formally, in EPP, "repository"). The (ii) Whois Server and Referral URL both provide metadata necessary for the operation of the distributed database that makes up the RDS (in systems other than whois, approximately the same data with the same relation to identity would be in place, but the details might be different. I think we can treat this as a class anyway). Finally, IANA has a registry of registrar IDs (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), and that contains their (iii) names. This is a protocol parameter registry, but it appears to be managed by ICANN so it is probably appropriate for this PDP to make the policy about how that is to be managed. a. Collection Data (i) and (ii) are all required to be collected under purposes 1 and 2. Without this data it is not possible to know the source of the data and it is not possible to trace it further in the system. Data (iii) needs to be collected in order to give (i) meaning, because it is the only way to know whether two IANA ids are bound to the same organization or person. b. Publication Data (i) are possibly required to be published under purpose 1. This largely depends on whether we think the identity of who is managing an object in the registry is part of the "lifecycle of a domain name". My feeling is "yes". Also, this information is likely to be disclosed anyway; see below. Data (ii) are required to be published under purposes 1 and 2, as long as there is at least one data element that is required under some purpose and is not available from the registry. (Since the actual registration life cycle is controlled by the registrar and not the registry, this appears likely.) Owing to the way these work, publication of these is likely to "leak" information about (i) or (iii) also. c. Maximal audience Given purposes 2 and 3 and probably 5, and since the source of contact information is registrars, the maximal audience is probably everyone on the Internet. If we think that purposes 2, 3, or 5 are limited in respect of who needs to make such contact or who needs to check accuracy, then the maximal audience is the set of all those who have such a need. It's worth observing, however, that at least the technical contact for a name ought to be contactable by anyone on the Internet, since when we want to "facilitate communication with domain contacts" at least part of the reason is as a fallback when a site breaks in some way. (This may suggest that we need to unpack the details of purpose 3.) 3. NAME SERVERS --------------- a. Collection Without collecting the name servers, domain names cannot function on the Internet, so this is required under purposes 1 and 2. (Given that the registration of the name itself and the collection of the name servers are both required for the basic functioning of the Internet Domain Name System, it strikes me that we may be missing a more obvious purpose in our list, but I guess (1) and (2) will be enough and we're already so late that I am loathe to suggest something more.) b. Publication Whenever a name is available on the Internet, the name server data is already available in the DNS, so this data is necessarily published. Under either purpose 1 or 2 (or both), the data about nameservers in the RDS provides an avenue for troubleshooting issues in the DNS, and so it is required for those purposes. c. Maximal audience Anyone who wants to access a site must be able to find this data in the DNS. Potentially anyone who has a problem with resolution can use the data in the RDS to aid in troubleshooting, so the audience under purpose 1 or 2 (or both) is everyone on the Internet. 4. STATUS VALUES ---------------- a. Collection The status values are not exactly "collected", but are at least in part the result of various actions by the sponsoring registrar and registry on the name. (Some can be set directly.) These govern the disposition of the name in question, and are a necessary condition for having a shared registration system, so they are required under purpose 1. b. Publication The status values govern the possible things that could be done to a name, and therefore the data must be published under purpose 1. c. Maximal audience At leasr some status values are required for doing some troubleshooting of resolution failures, so the audience for at least some values under purposes 1 or 2 is "everyone on the Internet". It is possible to argue that some of the status values are relevant only to those people who wish to perform some actions on the domain (such as transferring) or people in a position to do some kinds of activity (such as updating contact information). If we really think it necessary, we could undertake the exercise of audience evaluation for each EPP status. 5. DATES --------- While the dates might appear to be different kinds, they aren't, since for our purposes they all have at least one common utility (see below). a. Collection The dates, like status values, are not exactly "collected": they're a consequence of certain activities. They're necessary for the workings of the shared registration systems using the current fee-for-term model that (approximately?) all gTLD registries use today, so they're required under purpose 1. b. Publication The dates are required under purpose 1 or 2 in order to aid troubleshooting of resolution. (If a name worked yesterday and not today, it is helpful to know that it was just created -- meaning the old one was deleted -- or that it is expired, or that someone updated the name only last night.) c. Maximal audience Because of the troubleshooting aspects of these dates, the audience under purpose 1 or 2 is everyone on the Internet. -- 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
+1. What you're proposing is actually the approach taken in the EWG. We plumbed use cases wired to data elements. By that route we arrived at the minimal data set for unfettered disclosure and access then the gated elements for restricted access and heightened disclosure rules. -Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Mon, Mar 20, 2017 at 6:21 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
I left the meeting with data protection experts last week feeling quite strongly the need for a specific and concrete purpose for each datum we recommend to collect and to make available; and the need for a definition of who the maximal (appropriate) audience is (given the purpose).
At the same time, I think that a reasonably short and high-level statement of purpose along the lines that we have been preparing can provide a useful set of principles.
It strikes me that maybe we could take the high-level purpose statement, and go through some potential data elements and link each one concretely to at least one of the principles in our candidate list. In what follows I name these "purpose 1", "purpose 2", &c. The purposes are numbered according to the scheme in RDS PDP Phase 1: Key Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware that the details in the candidate list are still in flux, but I think the broad strokes are pretty close anyway, so I thought I'd try it with the "thin" data we agreed to start with. This mail is a little long because I'm dealing with all the classes of elements in one message. I suppose we could break this into one-thread-per-element (or class) if we don't converge quickly on each of them. The outline below is just my view, of course, though obviously I think that what I say is true. I use the "maximal audience" because I think that if there is any "whole public" use then there's no point considering more restrictive uses. (For instance, if we need the domain name to be published to everyone on the Internet because it won't work otherwise, then it makes no difference if LEOs want that data under some sort of authorized-access protocol, because they'll just get it under the wide-open rules instead. So we don't need to care about the LEO purpose in that case.) "Maximal audience" might not work for cases where two different classes have different needs both of which require some restrictions, but it's handy here because we're talking about thin data.
I'm sorry this is long, but I hope it is a useful contribution to the discussion.
Best regards,
A
---%<---cut here---
Here is a convenient example thin whois response, in case anyone wants it to for reference in what follows. (Among other things, it reminds me that something I started to do has never been completed, so thank you to this WG for reminding me of that. :-) )
Domain Name: ANVILWALRUSDEN.COM Registrar: TUCOWS DOMAINS INC. Sponsoring Registrar IANA ID: 69 Whois Server: whois.tucows.com Referral URL: http://www.tucowsdomains.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM Status: clientTransferProhibited https://icann.org/epp# clientTransferProhibited Status: clientUpdateProhibited https://icann.org/epp# clientUpdateProhibited Updated Date: 17-jan-2017 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017
1. DOMAIN NAME ---------------
a. Collection
The domain name is required to be collected under purpose 1. Without this, there is no domain name, so it is literally impossible to have anything to collect or publish.
b. Publication
The domain name is required to be published under purpose 1, because it is a key by which data is accessed. If you wish to look up the current data about a particular name, you use the name as the key by which you query. (This is not the only possible key. For instance, in an EPP registry you could in principle use the ROID to look up a particular name object. But that does not give you the current data for the thing so named; it just gives you the data about that Repository Object. Two different versions of the same name -- like if example.com is registered by Alice then deleted and later registered by Bob -- have different ROIDs.)
c. Maximal audience
The data audience is Internet-wide under purpose 1 or purpose 2 (or both). The domain name is by definition not private data, because domain names registered in DNS domain name registries (i.e. every registry possibly covered by ICANN policy -- the registries subordinate to the IANA DNS name registries) are name registration in a public name space. Note that it is not possible to keep the existence of a name private, because even if a name were initially undisclosed its existence would be disclosed whenever someone else tried to register it.
2. REGISTRAR IDENTITY -------------------
There are four items here, but three classes of data. The (i) registrar ID provides data about the entity that created the entry in the registry (formally, in EPP, "repository"). The (ii) Whois Server and Referral URL both provide metadata necessary for the operation of the distributed database that makes up the RDS (in systems other than whois, approximately the same data with the same relation to identity would be in place, but the details might be different. I think we can treat this as a class anyway). Finally, IANA has a registry of registrar IDs (https://www.iana.org/assignments/registrar-ids/ registrar-ids.xhtml#registrar-ids-1), and that contains their (iii) names. This is a protocol parameter registry, but it appears to be managed by ICANN so it is probably appropriate for this PDP to make the policy about how that is to be managed.
a. Collection
Data (i) and (ii) are all required to be collected under purposes 1 and 2. Without this data it is not possible to know the source of the data and it is not possible to trace it further in the system. Data (iii) needs to be collected in order to give (i) meaning, because it is the only way to know whether two IANA ids are bound to the same organization or person.
b. Publication
Data (i) are possibly required to be published under purpose 1. This largely depends on whether we think the identity of who is managing an object in the registry is part of the "lifecycle of a domain name". My feeling is "yes". Also, this information is likely to be disclosed anyway; see below.
Data (ii) are required to be published under purposes 1 and 2, as long as there is at least one data element that is required under some purpose and is not available from the registry. (Since the actual registration life cycle is controlled by the registrar and not the registry, this appears likely.) Owing to the way these work, publication of these is likely to "leak" information about (i) or (iii) also.
c. Maximal audience
Given purposes 2 and 3 and probably 5, and since the source of contact information is registrars, the maximal audience is probably everyone on the Internet. If we think that purposes 2, 3, or 5 are limited in respect of who needs to make such contact or who needs to check accuracy, then the maximal audience is the set of all those who have such a need. It's worth observing, however, that at least the technical contact for a name ought to be contactable by anyone on the Internet, since when we want to "facilitate communication with domain contacts" at least part of the reason is as a fallback when a site breaks in some way. (This may suggest that we need to unpack the details of purpose 3.)
3. NAME SERVERS ---------------
a. Collection
Without collecting the name servers, domain names cannot function on the Internet, so this is required under purposes 1 and 2. (Given that the registration of the name itself and the collection of the name servers are both required for the basic functioning of the Internet Domain Name System, it strikes me that we may be missing a more obvious purpose in our list, but I guess (1) and (2) will be enough and we're already so late that I am loathe to suggest something more.)
b. Publication
Whenever a name is available on the Internet, the name server data is already available in the DNS, so this data is necessarily published. Under either purpose 1 or 2 (or both), the data about nameservers in the RDS provides an avenue for troubleshooting issues in the DNS, and so it is required for those purposes.
c. Maximal audience
Anyone who wants to access a site must be able to find this data in the DNS. Potentially anyone who has a problem with resolution can use the data in the RDS to aid in troubleshooting, so the audience under purpose 1 or 2 (or both) is everyone on the Internet.
4. STATUS VALUES ----------------
a. Collection
The status values are not exactly "collected", but are at least in part the result of various actions by the sponsoring registrar and registry on the name. (Some can be set directly.) These govern the disposition of the name in question, and are a necessary condition for having a shared registration system, so they are required under purpose 1.
b. Publication
The status values govern the possible things that could be done to a name, and therefore the data must be published under purpose 1.
c. Maximal audience
At leasr some status values are required for doing some troubleshooting of resolution failures, so the audience for at least some values under purposes 1 or 2 is "everyone on the Internet". It is possible to argue that some of the status values are relevant only to those people who wish to perform some actions on the domain (such as transferring) or people in a position to do some kinds of activity (such as updating contact information). If we really think it necessary, we could undertake the exercise of audience evaluation for each EPP status.
5. DATES ---------
While the dates might appear to be different kinds, they aren't, since for our purposes they all have at least one common utility (see below).
a. Collection
The dates, like status values, are not exactly "collected": they're a consequence of certain activities. They're necessary for the workings of the shared registration systems using the current fee-for-term model that (approximately?) all gTLD registries use today, so they're required under purpose 1.
b. Publication
The dates are required under purpose 1 or 2 in order to aid troubleshooting of resolution. (If a name worked yesterday and not today, it is helpful to know that it was just created -- meaning the old one was deleted -- or that it is expired, or that someone updated the name only last night.)
c. Maximal audience
Because of the troubleshooting aspects of these dates, the audience under purpose 1 or 2 is everyone on the Internet.
-- 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
Thanks Andrew, really helpful. Stephanie Perrin On 2017-03-20 19:21, Andrew Sullivan wrote:
Hi,
I left the meeting with data protection experts last week feeling quite strongly the need for a specific and concrete purpose for each datum we recommend to collect and to make available; and the need for a definition of who the maximal (appropriate) audience is (given the purpose).
At the same time, I think that a reasonably short and high-level statement of purpose along the lines that we have been preparing can provide a useful set of principles.
It strikes me that maybe we could take the high-level purpose statement, and go through some potential data elements and link each one concretely to at least one of the principles in our candidate list. In what follows I name these "purpose 1", "purpose 2", &c. The purposes are numbered according to the scheme in RDS PDP Phase 1: Key Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware that the details in the candidate list are still in flux, but I think the broad strokes are pretty close anyway, so I thought I'd try it with the "thin" data we agreed to start with. This mail is a little long because I'm dealing with all the classes of elements in one message. I suppose we could break this into one-thread-per-element (or class) if we don't converge quickly on each of them. The outline below is just my view, of course, though obviously I think that what I say is true. I use the "maximal audience" because I think that if there is any "whole public" use then there's no point considering more restrictive uses. (For instance, if we need the domain name to be published to everyone on the Internet because it won't work otherwise, then it makes no difference if LEOs want that data under some sort of authorized-access protocol, because they'll just get it under the wide-open rules instead. So we don't need to care about the LEO purpose in that case.) "Maximal audience" might not work for cases where two different classes have different needs both of which require some restrictions, but it's handy here because we're talking about thin data.
I'm sorry this is long, but I hope it is a useful contribution to the discussion.
Best regards,
A
---%<---cut here---
Here is a convenient example thin whois response, in case anyone wants it to for reference in what follows. (Among other things, it reminds me that something I started to do has never been completed, so thank you to this WG for reminding me of that. :-) )
Domain Name: ANVILWALRUSDEN.COM Registrar: TUCOWS DOMAINS INC. Sponsoring Registrar IANA ID: 69 Whois Server: whois.tucows.com Referral URL: http://www.tucowsdomains.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Updated Date: 17-jan-2017 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017
1. DOMAIN NAME ---------------
a. Collection
The domain name is required to be collected under purpose 1. Without this, there is no domain name, so it is literally impossible to have anything to collect or publish.
b. Publication
The domain name is required to be published under purpose 1, because it is a key by which data is accessed. If you wish to look up the current data about a particular name, you use the name as the key by which you query. (This is not the only possible key. For instance, in an EPP registry you could in principle use the ROID to look up a particular name object. But that does not give you the current data for the thing so named; it just gives you the data about that Repository Object. Two different versions of the same name -- like if example.com is registered by Alice then deleted and later registered by Bob -- have different ROIDs.)
c. Maximal audience
The data audience is Internet-wide under purpose 1 or purpose 2 (or both). The domain name is by definition not private data, because domain names registered in DNS domain name registries (i.e. every registry possibly covered by ICANN policy -- the registries subordinate to the IANA DNS name registries) are name registration in a public name space. Note that it is not possible to keep the existence of a name private, because even if a name were initially undisclosed its existence would be disclosed whenever someone else tried to register it.
2. REGISTRAR IDENTITY -------------------
There are four items here, but three classes of data. The (i) registrar ID provides data about the entity that created the entry in the registry (formally, in EPP, "repository"). The (ii) Whois Server and Referral URL both provide metadata necessary for the operation of the distributed database that makes up the RDS (in systems other than whois, approximately the same data with the same relation to identity would be in place, but the details might be different. I think we can treat this as a class anyway). Finally, IANA has a registry of registrar IDs (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), and that contains their (iii) names. This is a protocol parameter registry, but it appears to be managed by ICANN so it is probably appropriate for this PDP to make the policy about how that is to be managed.
a. Collection
Data (i) and (ii) are all required to be collected under purposes 1 and 2. Without this data it is not possible to know the source of the data and it is not possible to trace it further in the system. Data (iii) needs to be collected in order to give (i) meaning, because it is the only way to know whether two IANA ids are bound to the same organization or person.
b. Publication
Data (i) are possibly required to be published under purpose 1. This largely depends on whether we think the identity of who is managing an object in the registry is part of the "lifecycle of a domain name". My feeling is "yes". Also, this information is likely to be disclosed anyway; see below.
Data (ii) are required to be published under purposes 1 and 2, as long as there is at least one data element that is required under some purpose and is not available from the registry. (Since the actual registration life cycle is controlled by the registrar and not the registry, this appears likely.) Owing to the way these work, publication of these is likely to "leak" information about (i) or (iii) also.
c. Maximal audience
Given purposes 2 and 3 and probably 5, and since the source of contact information is registrars, the maximal audience is probably everyone on the Internet. If we think that purposes 2, 3, or 5 are limited in respect of who needs to make such contact or who needs to check accuracy, then the maximal audience is the set of all those who have such a need. It's worth observing, however, that at least the technical contact for a name ought to be contactable by anyone on the Internet, since when we want to "facilitate communication with domain contacts" at least part of the reason is as a fallback when a site breaks in some way. (This may suggest that we need to unpack the details of purpose 3.)
3. NAME SERVERS ---------------
a. Collection
Without collecting the name servers, domain names cannot function on the Internet, so this is required under purposes 1 and 2. (Given that the registration of the name itself and the collection of the name servers are both required for the basic functioning of the Internet Domain Name System, it strikes me that we may be missing a more obvious purpose in our list, but I guess (1) and (2) will be enough and we're already so late that I am loathe to suggest something more.)
b. Publication
Whenever a name is available on the Internet, the name server data is already available in the DNS, so this data is necessarily published. Under either purpose 1 or 2 (or both), the data about nameservers in the RDS provides an avenue for troubleshooting issues in the DNS, and so it is required for those purposes.
c. Maximal audience
Anyone who wants to access a site must be able to find this data in the DNS. Potentially anyone who has a problem with resolution can use the data in the RDS to aid in troubleshooting, so the audience under purpose 1 or 2 (or both) is everyone on the Internet.
4. STATUS VALUES ----------------
a. Collection
The status values are not exactly "collected", but are at least in part the result of various actions by the sponsoring registrar and registry on the name. (Some can be set directly.) These govern the disposition of the name in question, and are a necessary condition for having a shared registration system, so they are required under purpose 1.
b. Publication
The status values govern the possible things that could be done to a name, and therefore the data must be published under purpose 1.
c. Maximal audience
At leasr some status values are required for doing some troubleshooting of resolution failures, so the audience for at least some values under purposes 1 or 2 is "everyone on the Internet". It is possible to argue that some of the status values are relevant only to those people who wish to perform some actions on the domain (such as transferring) or people in a position to do some kinds of activity (such as updating contact information). If we really think it necessary, we could undertake the exercise of audience evaluation for each EPP status.
5. DATES ---------
While the dates might appear to be different kinds, they aren't, since for our purposes they all have at least one common utility (see below).
a. Collection
The dates, like status values, are not exactly "collected": they're a consequence of certain activities. They're necessary for the workings of the shared registration systems using the current fee-for-term model that (approximately?) all gTLD registries use today, so they're required under purpose 1.
b. Publication
The dates are required under purpose 1 or 2 in order to aid troubleshooting of resolution. (If a name worked yesterday and not today, it is helpful to know that it was just created -- meaning the old one was deleted -- or that it is expired, or that someone updated the name only last night.)
c. Maximal audience
Because of the troubleshooting aspects of these dates, the audience under purpose 1 or 2 is everyone on the Internet.
Thank you very much Andrew for your thoughtful comments. It seems to me that they could help us make progress. Do you think that we need to develop a purpose for every data element in the RDS or would it suffice to develop a purpose for collection of RDS data elements, a purpose for public display of RDS data elements and a purpose for gated access to RDS data elements? If we considered data elements by class, what would you suggest are the classes? Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Monday, March 20, 2017 7:22 PM To: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi, I left the meeting with data protection experts last week feeling quite strongly the need for a specific and concrete purpose for each datum we recommend to collect and to make available; and the need for a definition of who the maximal (appropriate) audience is (given the purpose). At the same time, I think that a reasonably short and high-level statement of purpose along the lines that we have been preparing can provide a useful set of principles. It strikes me that maybe we could take the high-level purpose statement, and go through some potential data elements and link each one concretely to at least one of the principles in our candidate list. In what follows I name these "purpose 1", "purpose 2", &c. The purposes are numbered according to the scheme in RDS PDP Phase 1: Key Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware that the details in the candidate list are still in flux, but I think the broad strokes are pretty close anyway, so I thought I'd try it with the "thin" data we agreed to start with. This mail is a little long because I'm dealing with all the classes of elements in one message. I suppose we could break this into one-thread-per-element (or class) if we don't converge quickly on each of them. The outline below is just my view, of course, though obviously I think that what I say is true. I use the "maximal audience" because I think that if there is any "whole public" use then there's no point considering more restrictive uses. (For instance, if we need the domain name to be published to everyone on the Internet because it won't work otherwise, then it makes no difference if LEOs want that data under some sort of authorized-access protocol, because they'll just get it under the wide-open rules instead. So we don't need to care about the LEO purpose in that case.) "Maximal audience" might not work for cases where two different classes have different needs both of which require some restrictions, but it's handy here because we're talking about thin data. I'm sorry this is long, but I hope it is a useful contribution to the discussion. Best regards, A ---%<---cut here--- Here is a convenient example thin whois response, in case anyone wants it to for reference in what follows. (Among other things, it reminds me that something I started to do has never been completed, so thank you to this WG for reminding me of that. :-) ) Domain Name: ANVILWALRUSDEN.COM Registrar: TUCOWS DOMAINS INC. Sponsoring Registrar IANA ID: 69 Whois Server: whois.tucows.com Referral URL: http://www.tucowsdomains.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Updated Date: 17-jan-2017 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017 1. DOMAIN NAME --------------- a. Collection The domain name is required to be collected under purpose 1. Without this, there is no domain name, so it is literally impossible to have anything to collect or publish. b. Publication The domain name is required to be published under purpose 1, because it is a key by which data is accessed. If you wish to look up the current data about a particular name, you use the name as the key by which you query. (This is not the only possible key. For instance, in an EPP registry you could in principle use the ROID to look up a particular name object. But that does not give you the current data for the thing so named; it just gives you the data about that Repository Object. Two different versions of the same name -- like if example.com is registered by Alice then deleted and later registered by Bob -- have different ROIDs.) c. Maximal audience The data audience is Internet-wide under purpose 1 or purpose 2 (or both). The domain name is by definition not private data, because domain names registered in DNS domain name registries (i.e. every registry possibly covered by ICANN policy -- the registries subordinate to the IANA DNS name registries) are name registration in a public name space. Note that it is not possible to keep the existence of a name private, because even if a name were initially undisclosed its existence would be disclosed whenever someone else tried to register it. 2. REGISTRAR IDENTITY ------------------- There are four items here, but three classes of data. The (i) registrar ID provides data about the entity that created the entry in the registry (formally, in EPP, "repository"). The (ii) Whois Server and Referral URL both provide metadata necessary for the operation of the distributed database that makes up the RDS (in systems other than whois, approximately the same data with the same relation to identity would be in place, but the details might be different. I think we can treat this as a class anyway). Finally, IANA has a registry of registrar IDs (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), and that contains their (iii) names. This is a protocol parameter registry, but it appears to be managed by ICANN so it is probably appropriate for this PDP to make the policy about how that is to be managed. a. Collection Data (i) and (ii) are all required to be collected under purposes 1 and 2. Without this data it is not possible to know the source of the data and it is not possible to trace it further in the system. Data (iii) needs to be collected in order to give (i) meaning, because it is the only way to know whether two IANA ids are bound to the same organization or person. b. Publication Data (i) are possibly required to be published under purpose 1. This largely depends on whether we think the identity of who is managing an object in the registry is part of the "lifecycle of a domain name". My feeling is "yes". Also, this information is likely to be disclosed anyway; see below. Data (ii) are required to be published under purposes 1 and 2, as long as there is at least one data element that is required under some purpose and is not available from the registry. (Since the actual registration life cycle is controlled by the registrar and not the registry, this appears likely.) Owing to the way these work, publication of these is likely to "leak" information about (i) or (iii) also. c. Maximal audience Given purposes 2 and 3 and probably 5, and since the source of contact information is registrars, the maximal audience is probably everyone on the Internet. If we think that purposes 2, 3, or 5 are limited in respect of who needs to make such contact or who needs to check accuracy, then the maximal audience is the set of all those who have such a need. It's worth observing, however, that at least the technical contact for a name ought to be contactable by anyone on the Internet, since when we want to "facilitate communication with domain contacts" at least part of the reason is as a fallback when a site breaks in some way. (This may suggest that we need to unpack the details of purpose 3.) 3. NAME SERVERS --------------- a. Collection Without collecting the name servers, domain names cannot function on the Internet, so this is required under purposes 1 and 2. (Given that the registration of the name itself and the collection of the name servers are both required for the basic functioning of the Internet Domain Name System, it strikes me that we may be missing a more obvious purpose in our list, but I guess (1) and (2) will be enough and we're already so late that I am loathe to suggest something more.) b. Publication Whenever a name is available on the Internet, the name server data is already available in the DNS, so this data is necessarily published. Under either purpose 1 or 2 (or both), the data about nameservers in the RDS provides an avenue for troubleshooting issues in the DNS, and so it is required for those purposes. c. Maximal audience Anyone who wants to access a site must be able to find this data in the DNS. Potentially anyone who has a problem with resolution can use the data in the RDS to aid in troubleshooting, so the audience under purpose 1 or 2 (or both) is everyone on the Internet. 4. STATUS VALUES ---------------- a. Collection The status values are not exactly "collected", but are at least in part the result of various actions by the sponsoring registrar and registry on the name. (Some can be set directly.) These govern the disposition of the name in question, and are a necessary condition for having a shared registration system, so they are required under purpose 1. b. Publication The status values govern the possible things that could be done to a name, and therefore the data must be published under purpose 1. c. Maximal audience At leasr some status values are required for doing some troubleshooting of resolution failures, so the audience for at least some values under purposes 1 or 2 is "everyone on the Internet". It is possible to argue that some of the status values are relevant only to those people who wish to perform some actions on the domain (such as transferring) or people in a position to do some kinds of activity (such as updating contact information). If we really think it necessary, we could undertake the exercise of audience evaluation for each EPP status. 5. DATES --------- While the dates might appear to be different kinds, they aren't, since for our purposes they all have at least one common utility (see below). a. Collection The dates, like status values, are not exactly "collected": they're a consequence of certain activities. They're necessary for the workings of the shared registration systems using the current fee-for-term model that (approximately?) all gTLD registries use today, so they're required under purpose 1. b. Publication The dates are required under purpose 1 or 2 in order to aid troubleshooting of resolution. (If a name worked yesterday and not today, it is helpful to know that it was just created -- meaning the old one was deleted -- or that it is expired, or that someone updated the name only last night.) c. Maximal audience Because of the troubleshooting aspects of these dates, the audience under purpose 1 or 2 is everyone on the Internet. -- 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
I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this. The practice of charging someone extra for the use of their privacy rights (and for the registrar to do less work) is the pathological business model at the center of all of this. If consumers have a true choice and I decided to publish my email and phone number, that is my choice to make. Sent from my iPhone
On Mar 21, 2017, at 13:06, Gomes, Chuck via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
Thank you very much Andrew for your thoughtful comments. It seems to me that they could help us make progress.
Do you think that we need to develop a purpose for every data element in the RDS or would it suffice to develop a purpose for collection of RDS data elements, a purpose for public display of RDS data elements and a purpose for gated access to RDS data elements?
If we considered data elements by class, what would you suggest are the classes?
Chuck
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Monday, March 20, 2017 7:22 PM To: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi,
I left the meeting with data protection experts last week feeling quite strongly the need for a specific and concrete purpose for each datum we recommend to collect and to make available; and the need for a definition of who the maximal (appropriate) audience is (given the purpose).
At the same time, I think that a reasonably short and high-level statement of purpose along the lines that we have been preparing can provide a useful set of principles.
It strikes me that maybe we could take the high-level purpose statement, and go through some potential data elements and link each one concretely to at least one of the principles in our candidate list. In what follows I name these "purpose 1", "purpose 2", &c. The purposes are numbered according to the scheme in RDS PDP Phase 1: Key Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware that the details in the candidate list are still in flux, but I think the broad strokes are pretty close anyway, so I thought I'd try it with the "thin" data we agreed to start with. This mail is a little long because I'm dealing with all the classes of elements in one message. I suppose we could break this into one-thread-per-element (or class) if we don't converge quickly on each of them. The outline below is just my view, of course, though obviously I think that what I say is true. I use the "maximal audience" because I think that if there is any "whole public" use then there's no point considering more restrictive uses. (For instance, if we need the domain name to be published to everyone on the Internet because it won't work otherwise, then it makes no difference if LEOs want that data under some sort of authorized-access protocol, because they'll just get it under the wide-open rules instead. So we don't need to care about the LEO purpose in that case.) "Maximal audience" might not work for cases where two different classes have different needs both of which require some restrictions, but it's handy here because we're talking about thin data.
I'm sorry this is long, but I hope it is a useful contribution to the discussion.
Best regards,
A
---%<---cut here---
Here is a convenient example thin whois response, in case anyone wants it to for reference in what follows. (Among other things, it reminds me that something I started to do has never been completed, so thank you to this WG for reminding me of that. :-) )
Domain Name: ANVILWALRUSDEN.COM Registrar: TUCOWS DOMAINS INC. Sponsoring Registrar IANA ID: 69 Whois Server: whois.tucows.com Referral URL: http://www.tucowsdomains.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Updated Date: 17-jan-2017 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017
1. DOMAIN NAME ---------------
a. Collection
The domain name is required to be collected under purpose 1. Without this, there is no domain name, so it is literally impossible to have anything to collect or publish.
b. Publication
The domain name is required to be published under purpose 1, because it is a key by which data is accessed. If you wish to look up the current data about a particular name, you use the name as the key by which you query. (This is not the only possible key. For instance, in an EPP registry you could in principle use the ROID to look up a particular name object. But that does not give you the current data for the thing so named; it just gives you the data about that Repository Object. Two different versions of the same name -- like if example.com is registered by Alice then deleted and later registered by Bob -- have different ROIDs.)
c. Maximal audience
The data audience is Internet-wide under purpose 1 or purpose 2 (or both). The domain name is by definition not private data, because domain names registered in DNS domain name registries (i.e. every registry possibly covered by ICANN policy -- the registries subordinate to the IANA DNS name registries) are name registration in a public name space. Note that it is not possible to keep the existence of a name private, because even if a name were initially undisclosed its existence would be disclosed whenever someone else tried to register it.
2. REGISTRAR IDENTITY -------------------
There are four items here, but three classes of data. The (i) registrar ID provides data about the entity that created the entry in the registry (formally, in EPP, "repository"). The (ii) Whois Server and Referral URL both provide metadata necessary for the operation of the distributed database that makes up the RDS (in systems other than whois, approximately the same data with the same relation to identity would be in place, but the details might be different. I think we can treat this as a class anyway). Finally, IANA has a registry of registrar IDs (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), and that contains their (iii) names. This is a protocol parameter registry, but it appears to be managed by ICANN so it is probably appropriate for this PDP to make the policy about how that is to be managed.
a. Collection
Data (i) and (ii) are all required to be collected under purposes 1 and 2. Without this data it is not possible to know the source of the data and it is not possible to trace it further in the system. Data (iii) needs to be collected in order to give (i) meaning, because it is the only way to know whether two IANA ids are bound to the same organization or person.
b. Publication
Data (i) are possibly required to be published under purpose 1. This largely depends on whether we think the identity of who is managing an object in the registry is part of the "lifecycle of a domain name". My feeling is "yes". Also, this information is likely to be disclosed anyway; see below.
Data (ii) are required to be published under purposes 1 and 2, as long as there is at least one data element that is required under some purpose and is not available from the registry. (Since the actual registration life cycle is controlled by the registrar and not the registry, this appears likely.) Owing to the way these work, publication of these is likely to "leak" information about (i) or (iii) also.
c. Maximal audience
Given purposes 2 and 3 and probably 5, and since the source of contact information is registrars, the maximal audience is probably everyone on the Internet. If we think that purposes 2, 3, or 5 are limited in respect of who needs to make such contact or who needs to check accuracy, then the maximal audience is the set of all those who have such a need. It's worth observing, however, that at least the technical contact for a name ought to be contactable by anyone on the Internet, since when we want to "facilitate communication with domain contacts" at least part of the reason is as a fallback when a site breaks in some way. (This may suggest that we need to unpack the details of purpose 3.)
3. NAME SERVERS ---------------
a. Collection
Without collecting the name servers, domain names cannot function on the Internet, so this is required under purposes 1 and 2. (Given that the registration of the name itself and the collection of the name servers are both required for the basic functioning of the Internet Domain Name System, it strikes me that we may be missing a more obvious purpose in our list, but I guess (1) and (2) will be enough and we're already so late that I am loathe to suggest something more.)
b. Publication
Whenever a name is available on the Internet, the name server data is already available in the DNS, so this data is necessarily published. Under either purpose 1 or 2 (or both), the data about nameservers in the RDS provides an avenue for troubleshooting issues in the DNS, and so it is required for those purposes.
c. Maximal audience
Anyone who wants to access a site must be able to find this data in the DNS. Potentially anyone who has a problem with resolution can use the data in the RDS to aid in troubleshooting, so the audience under purpose 1 or 2 (or both) is everyone on the Internet.
4. STATUS VALUES ----------------
a. Collection
The status values are not exactly "collected", but are at least in part the result of various actions by the sponsoring registrar and registry on the name. (Some can be set directly.) These govern the disposition of the name in question, and are a necessary condition for having a shared registration system, so they are required under purpose 1.
b. Publication
The status values govern the possible things that could be done to a name, and therefore the data must be published under purpose 1.
c. Maximal audience
At leasr some status values are required for doing some troubleshooting of resolution failures, so the audience for at least some values under purposes 1 or 2 is "everyone on the Internet". It is possible to argue that some of the status values are relevant only to those people who wish to perform some actions on the domain (such as transferring) or people in a position to do some kinds of activity (such as updating contact information). If we really think it necessary, we could undertake the exercise of audience evaluation for each EPP status.
5. DATES ---------
While the dates might appear to be different kinds, they aren't, since for our purposes they all have at least one common utility (see below).
a. Collection
The dates, like status values, are not exactly "collected": they're a consequence of certain activities. They're necessary for the workings of the shared registration systems using the current fee-for-term model that (approximately?) all gTLD registries use today, so they're required under purpose 1.
b. Publication
The dates are required under purpose 1 or 2 in order to aid troubleshooting of resolution. (If a name worked yesterday and not today, it is helpful to know that it was just created -- meaning the old one was deleted -- or that it is expired, or that someone updated the name only last night.)
c. Maximal audience
Because of the troubleshooting aspects of these dates, the audience under purpose 1 or 2 is everyone on the Internet.
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote:
I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this.
I don't see how. The experts last week were quite clear that the first question is about collection, and our PDP is chartered to talk about that too, so we have to discuss whether some of this data should be collected at all, and if so by whom. A -- Andrew Sullivan ajs@anvilwalrusden.com
And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question. Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced. Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world. It isn't an ancillary question. Its the fundamental one. Sent from my iPhone
On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com" <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this.
I don't see how. The experts last week were quite clear that the first question is about collection, and our PDP is chartered to talk about that too, so we have to discuss whether some of this data should be collected at all, and if so by whom.
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
I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well. On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question.
Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced.
Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world.
It isn't an ancillary question. Its the fundamental one.
Sent from my iPhone
On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com" < ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this.
I don't see how. The experts last week were quite clear that the first question is about collection, and our PDP is chartered to talk about that too, so we have to discuss whether some of this data should be collected at all, and if so by whom.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
Indeed, the WHOIS disclosure instrument may be the thing that sticks in everybody's mind, but it is not the first place to start in addressing a comprehensive approach to RDS privacy. First you have to address why you are collecting each data element. Is the core purpose justifiable and proportionate? etc, we spent an hour on it with Mr. Canatacci and we are not done yet.... Yes, privacy proxy services have been the stop gap over the years. The data is still being collected without a clear statement of purpose, disclosed in a variety of ways that may not pass muster, retained in violation of at least EU law and likely others, data subject access and disclosure rights inadequately addressed...... Lets wait till we get our answers to the questions before we start discussing possible solutions. I think we are jumping ahead quite a bit. Stephanie Perrin On 2017-03-21 15:18, allison nixon wrote:
I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well.
On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question.
Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced.
Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world.
It isn't an ancillary question. Its the fundamental one.
Sent from my iPhone
> On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>" <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote: > >> On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: >> I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this. > > I don't see how. The experts last week were quite clear that the > first question is about collection, and our PDP is chartered to talk > about that too, so we have to discuss whether some of this data should > be collected at all, and if so by whom. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> > _______________________________________________ > 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free. The question of whether fields are optional or can be "masked" is inherently part of this discussion. That being said I would like to add purposes to why data is collected in RDS. Some suggestions: To enable third-parties to communicate directly to resolve and troubleshoot problems. To enable third-parties to report abuse or security incidents so they may be resolved. To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news). ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important. J Sent from my iPhone
On Mar 21, 2017, at 14:49, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote:
Indeed, the WHOIS disclosure instrument may be the thing that sticks in everybody's mind, but it is not the first place to start in addressing a comprehensive approach to RDS privacy. First you have to address why you are collecting each data element. Is the core purpose justifiable and proportionate? etc, we spent an hour on it with Mr. Canatacci and we are not done yet....
Yes, privacy proxy services have been the stop gap over the years. The data is still being collected without a clear statement of purpose, disclosed in a variety of ways that may not pass muster, retained in violation of at least EU law and likely others, data subject access and disclosure rights inadequately addressed......
Lets wait till we get our answers to the questions before we start discussing possible solutions. I think we are jumping ahead quite a bit.
Stephanie Perrin
On 2017-03-21 15:18, allison nixon wrote: I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well.
On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question.
Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced.
Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world.
It isn't an ancillary question. Its the fundamental one.
Sent from my iPhone
On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com" <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this.
I don't see how. The experts last week were quite clear that the first question is about collection, and our PDP is chartered to talk about that too, so we have to discuss whether some of this data should be collected at all, and if so by whom.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free.
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
The question of whether fields are optional or can be "masked" is inherently part of this discussion.
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news).
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important.
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion.But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against. My .02 cents Nathalie On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free.
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
The question of whether fields are optional or can be "masked" is inherently part of this discussion.
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news).
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important.
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois. Sent from my iPhone
On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against.
My .02 cents
Nathalie
On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free.
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
The question of whether fields are optional or can be "masked" is inherently part of this discussion.
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news).
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important.
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
not only is the pattern of lying useful, but the create/expiration dates are useful for determining if an old domain is still owned by the original registrar account(or someone they authorized a transfer to), or if it has dropped and been re-registered, important for detecting impersonation. When we do see a malicious domain using whois to impersonate someone by copying their info, that gives stronger legal justification to take it down. on a practical day to day basis, whois is legitimately more useful than any certificates for determining the authenticity of a site, because years of whois archives tell me about the actual legitimacy of the people behind it. Does the story they tell in the whois match up with the story I hear from somewhere else? Whois is the rope with which bad actors hang themselves. For every piece of data that is already gathered under the most comprehensive WHOIS regime, there is a strong industry backed argument that the data needs to continue being collected, and for it to remain available. So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois.
Sent from my iPhone
On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against.
My .02 cents
Nathalie
On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan < ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free.
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
The question of whether fields are optional or can be "masked" is inherently part of this discussion.
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news).
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important.
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
Whois is the rope with which bad actors hang themselves.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
For every piece of data that is already gathered under the most comprehensive WHOIS regime, there is a strong industry backed argument that the data needs to continue being collected, and for it to remain available. Which industry? Not the domain industry. And when it comes to collection and handling of private data, our purposes for it is all that matters legally unless there is a requirement by law to collect and store.But in that case, compliance with local law would be the acceptable purpose.
To drive the point home: the purposes of third parties, including law enforcement have no relevance to the legal requirements for the collection and handling of private data. None whatsoever! But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc...
So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true.
Best, Volker
On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois.
Sent from my iPhone
On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against.
My .02 cents Nathalie
On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote: > Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free. >
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
> The question of whether fields are optional or can be "masked" is inherently part of this discussion. >
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
> To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
> To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
> To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news). >
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
> ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important. >
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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.
Inline On 03/23/2017 04:04 AM, Volker Greimann wrote:
Whois is the rope with which bad actors hang themselves.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I think maybe its best you let the people who do this work speak for the value of the information. We're using it in criminal investigations and prosecutions. You're just simply taking their money.
For every piece of data that is already gathered under the most comprehensive WHOIS regime, there is a strong industry backed argument that the data needs to continue being collected, and for it to remain available. Which industry? Not the domain industry. And when it comes to collection and handling of private data, our purposes for it is all that matters legally unless there is a requirement by law to collect and store.But in that case, compliance with local law would be the acceptable purpose.
Yes, you've made your position quite clear. But ICANN nor this group is a trade association of registrars solely focused on maximizing your profits and minimizing your expenses and allowing you to dump all the risk on society at large. But there are other voices here and that's what the multi-stakeholder model is, it means you don't get to be the only one talking.
To drive the point home: the purposes of third parties, including law enforcement have no relevance to the legal requirements for the collection and handling of private data. None whatsoever!
You have a contract with ICANN, that contract establishes requirements. Those requirements make it legal.
But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc...
ICANN sets the rules, you get to follow them. You get a voice, we get a voice. That's how contracts work. Chuck, this is why we're in trench warfare. And it isn't going to change.
So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true.
Best, Volker
On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois.
Sent from my iPhone
On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against.
My .02 cents
Nathalie
On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote: > Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free. >
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
> The question of whether fields are optional or can be "masked" is inherently part of this discussion. >
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
> To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
> To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
> To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news). >
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
> ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important. >
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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
Here we go again with the baseless allegations.
Whois is the rope with which bad actors hang themselves.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I think maybe its best you let the people who do this work speak for the value of the information. We're using it in criminal investigations and prosecutions. You're just simply taking their money. Believe it or not, bad actors cost us money. We'd love to be able to "not to take their money" as it is a poisoned pill. And we see the whois data used by criminals all the time, when we look at the reports we are sent. Usually it is fake data ripped from some online database or the phone book.
For every piece of data that is already gathered under the most comprehensive WHOIS regime, there is a strong industry backed argument that the data needs to continue being collected, and for it to remain available. Which industry? Not the domain industry. And when it comes to collection and handling of private data, our purposes for it is all that matters legally unless there is a requirement by law to collect and store.But in that case, compliance with local law would be the acceptable purpose.
Yes, you've made your position quite clear. But ICANN nor this group is a trade association of registrars solely focused on maximizing your profits and minimizing your expenses and allowing you to dump all the risk on society at large. But there are other voices here and that's what the multi-stakeholder model is, it means you don't get to be the only one talking.
The multistakeholder model does not trump applicable law. You can demand anything you want, but when it violates our legal requirements, it will not fly. This is not an issue that is even up for debate. If 99% of this WG demanded something that was illegal to implement, it still will be turned down. Collect your consolation prize over at the booth of the local governments.
To drive the point home: the purposes of third parties, including law enforcement have no relevance to the legal requirements for the collection and handling of private data. None whatsoever!
You have a contract with ICANN, that contract establishes requirements. Those requirements make it legal. If you believe that, you probably still believe in Trump and other things as well. The above statement is so supendiously wrong, it boggles the mind. You are basically saying that a contract to break the law somehow makes it ok to do so? So if we signed a contract tomorrow to rob the local bank, that absolves us from any guilt?
For clarity: The contract with ICANN can say that pigs may fly, but that does not change the laws of physics. If anything in the contract or ICANN policies violates applicable law, that part of the contract is null and void, does not apply, can be ignored, has no relevance, etc, etc. BTW: it even says so in the RAA. Maybe you can find the relevant passage yourself...
But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc...
ICANN sets the rules, you get to follow them.
If ICANN sets illegal rules, we get to ignore them. So why set illegal rules in the first place? To trap the unwitting and careless registrars?
You get a voice, we get a voice. Your voice can demand anything it likes, but if it is not in compliance with the law, it will be ignored. And rightly so. That's how contracts work. Nope! Contracts do not allow a contracted party to break the law. There is a reason assassination contracts are illegal.
Chuck, this is why we're in trench warfare. And it isn't going to change. Appears so. If one side continues to demand the illegal and the impossible for their own benefit, we will get nowhere. So why not educate yourself on the requirements of current and upcoming privacy regulations and afterwards, we can talk again...
So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true.
Best, Volker
On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois.
Sent from my iPhone
On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against.
My .02 cents Nathalie
On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote: > Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free. >
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
> The question of whether fields are optional or can be "masked" is inherently part of this discussion. >
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
> To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
> To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
> To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news). >
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
> ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important. >
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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.
Sent from my iPhone
On Mar 23, 2017, at 09:08, Volker Greimann <vgreimann@key-systems.net> wrote:
Here we go again with the baseless allegations.
Whois is the rope with which bad actors hang themselves.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I think maybe its best you let the people who do this work speak for the value of the information. We're using it in criminal investigations and prosecutions. You're just simply taking their money. Believe it or not, bad actors cost us money. We'd love to be able to "not to take their money" as it is a poisoned pill. And we see the whois data used by criminals all the time, when we look at the reports we are sent. Usually it is fake data ripped from some online database or the phone book.
So its a baseless allegation that investigators might have expertise in how they use this data? Only domain registrars who have a financial relationship with the criminals know how to use this data?
For every piece of data that is already gathered under the most comprehensive WHOIS regime, there is a strong industry backed argument that the data needs to continue being collected, and for it to remain available. Which industry? Not the domain industry. And when it comes to collection and handling of private data, our purposes for it is all that matters legally unless there is a requirement by law to collect and store.But in that case, compliance with local law would be the acceptable purpose.
Yes, you've made your position quite clear. But ICANN nor this group is a trade association of registrars solely focused on maximizing your profits and minimizing your expenses and allowing you to dump all the risk on society at large. But there are other voices here and that's what the multi-stakeholder model is, it means you don't get to be the only one talking.
The multistakeholder model does not trump applicable law. You can demand anything you want, but when it violates our legal requirements, it will not fly. This is not an issue that is even up for debate. If 99% of this WG demanded something that was illegal to implement, it still will be turned down. Collect your consolation prize over at the booth of the local governments.
I have used the law to craft a possible solution but no DP authority has taken your position. You are simply taking the position that if your profits aren't maximized and your costs aren't minimized it is illegal. This position is untenable.
To drive the point home: the purposes of third parties, including law enforcement have no relevance to the legal requirements for the collection and handling of private data. None whatsoever!
You have a contract with ICANN, that contract establishes requirements. Those requirements make it legal. If you believe that, you probably still believe in Trump and other things as well. The above statement is so supendiously wrong, it boggles the mind. You are basically saying that a contract to break the law somehow makes it ok to do so? So if we signed a contract tomorrow to rob the local bank, that absolves us from any guilt?
No one care about your inane political opinions.
For clarity: The contract with ICANN can say that pigs may fly, but that does not change the laws of physics. If anything in the contract or ICANN policies violates applicable law, that part of the contract is null and void, does not apply, can be ignored, has no relevance, etc, etc. BTW: it even says so in the RAA. Maybe you can find the relevant passage yourself...
If you have the law on your side, pound the law. If you have the facts on your side, pound the facts. Since you have neither, you pound the table.
But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc...
ICANN sets the rules, you get to follow them.
If ICANN sets illegal rules, we get to ignore them. So why set illegal rules in the first place? To trap the unwitting and careless registrars?
You get a voice, we get a voice.
Your voice can demand anything it likes, but if it is not in compliance with the law, it will be ignored. And rightly so.
That's how contracts work. Nope! Contracts do not allow a contracted party to break the law. There is a reason assassination contracts are illegal.
No one is suggesting you break the law. Calm down.
Chuck, this is why we're in trench warfare. And it isn't going to change. Appears so. If one side continues to demand the illegal and the impossible for their own benefit, we will get nowhere. So why not educate yourself on the requirements of current and upcoming privacy regulations and afterwards, we can talk again...
No one is demanding anything illegal.
So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true.
Best, Volker
On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois.
Sent from my iPhone
On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against.
My .02 cents
Nathalie
On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote: > Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free. >
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
> The question of whether fields are optional or can be "masked" is inherently part of this discussion. >
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
> To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
> To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
> To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news). >
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
> ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important. >
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Whois is the rope with which bad actors hang themselves.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I think maybe its best you let the people who do this work speak for the value of the information. We're using it in criminal investigations and prosecutions. You're just simply taking their money. Believe it or not, bad actors cost us money. We'd love to be able to "not to take their money" as it is a poisoned pill. And we see the whois data used by criminals all the time, when we look at the reports we are sent. Usually it is fake data ripped from some online database or the phone book.
So its a baseless allegation that investigators might have expertise in how they use this data? Only domain registrars who have a financial relationship with the criminals know how to use this data? I referred to your last sentence which directly implied that registrars in general and the registrar I am employed with in particular profit from criminals using their service. This is a baseless allegation that could not be farther from the truth, as I have previously explained.
I have used the law to craft a possible solution but no DP authority has taken your position. Ultimately, that may be the road we have to take if no better solution to provide registrar services legally presents itself, but as I pointed out, that will ultimately serve no one. Registrars will have to raise their fees to incorporate the service, crime fighters and LEAs will have a much more difficult time getting ANY data across borders. Your "solution" would just make your own work a lot harder.
You are simply taking the position that if your profits aren't maximized and your costs aren't minimized it is illegal. This position is untenable. Again, I resent you putting words into my mouth. Please do not make statements on my behalf or try to turn your assumptions into a claim of what I am saying. I am saying that anything we come up with will have to be in full compliance with legal requirements. And if there is a cost attached to that solution, that cost will be passed on somewhere, one way or another, not because I want it to but because I know that is the way it works.
You have a contract with ICANN, that contract establishes requirements. Those requirements make it legal. If you believe that, you probably still believe in Trump and other things as well. The above statement is so supendiously wrong, it boggles the mind. You are basically saying that a contract to break the law somehow makes it ok to do so? So if we signed a contract tomorrow to rob the local bank, that absolves us from any guilt?
No one care about your inane political opinions.
So I was right? Also good attempt at dodging the argument, but the point I made still stands.
For clarity: The contract with ICANN can say that pigs may fly, but that does not change the laws of physics. If anything in the contract or ICANN policies violates applicable law, that part of the contract is null and void, does not apply, can be ignored, has no relevance, etc, etc. BTW: it even says so in the RAA. Maybe you can find the relevant passage yourself...
If you have the law on your side, pound the law. If you have the facts on your side, pound the facts. Since you have neither, you pound the table.
Just because you appear not to like the facts or the laws, they do not become less applicable.
But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc...
ICANN sets the rules, you get to follow them.
If ICANN sets illegal rules, we get to ignore them. So why set illegal rules in the first place? To trap the unwitting and careless registrars?
You get a voice, we get a voice. Your voice can demand anything it likes, but if it is not in compliance with the law, it will be ignored. And rightly so. That's how contracts work. Nope! Contracts do not allow a contracted party to break the law. There is a reason assassination contracts are illegal.
No one is suggesting you break the law. Calm down.
Chuck, this is why we're in trench warfare. And it isn't going to change. Appears so. If one side continues to demand the illegal and the impossible for their own benefit, we will get nowhere. So why not educate yourself on the requirements of current and upcoming privacy regulations and afterwards, we can talk again...
No one is demanding anything illegal.
So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true.
Best, Volker
On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois.
Sent from my iPhone
On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against.
My .02 cents Nathalie
On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote: > Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free. >
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
> The question of whether fields are optional or can be "masked" is inherently part of this discussion. >
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
> To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
> To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
> To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news). >
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
> ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important. >
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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.
_______________________________________________ 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.
Sent from my iPhone
On Mar 23, 2017, at 09:44, Volker Greimann <vgreimann@key-systems.net> wrote:
Whois is the rope with which bad actors hang themselves.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I think maybe its best you let the people who do this work speak for the value of the information. We're using it in criminal investigations and prosecutions. You're just simply taking their money. Believe it or not, bad actors cost us money. We'd love to be able to "not to take their money" as it is a poisoned pill. And we see the whois data used by criminals all the time, when we look at the reports we are sent. Usually it is fake data ripped from some online database or the phone book.
So its a baseless allegation that investigators might have expertise in how they use this data? Only domain registrars who have a financial relationship with the criminals know how to use this data? I referred to your last sentence which directly implied that registrars in general and the registrar I am employed with in particular profit from criminals using their service. This is a baseless allegation that could not be farther from the truth, as I have previously explained.
That's a rather dramatic misreading. We investigate crimes so I would appreciate due deference to what data is valuable or not. Your role here is providing a service. You don't work with law enforcement to investigate crimes, do you?
I have used the law to craft a possible solution but no DP authority has taken your position. Ultimately, that may be the road we have to take if no better solution to provide registrar services legally presents itself, but as I pointed out, that will ultimately serve no one. Registrars will have to raise their fees to incorporate the service, crime fighters and LEAs will have a much more difficult time getting ANY data across borders. Your "solution" would just make your own work a lot harder.
I think perhaps deference to my opinion as to what would make MY work harder might be warranted. If you agree, I offer the same deference to you in matters in which your expertise is germane. Deal?
You are simply taking the position that if your profits aren't maximized and your costs aren't minimized it is illegal. This position is untenable. Again, I resent you putting words into my mouth. Please do not make statements on my behalf or try to turn your assumptions into a claim of what I am saying. I am saying that anything we come up with will have to be in full compliance with legal requirements. And if there is a cost attached to that solution, that cost will be passed on somewhere, one way or another, not because I want it to but because I know that is the way it works.
To which I agree. Let's craft a legal solution the represents the best of what we can offer for all ours (you, me, and everyone else's) interests. I think we can do balance. Will you join me in trying?
You have a contract with ICANN, that contract establishes requirements. Those requirements make it legal. If you believe that, you probably still believe in Trump and other things as well. The above statement is so supendiously wrong, it boggles the mind. You are basically saying that a contract to break the law somehow makes it ok to do so? So if we signed a contract tomorrow to rob the local bank, that absolves us from any guilt?
No one care about your inane political opinions.
So I was right? Also good attempt at dodging the argument, but the point I made still stands.
No, I just don't think constantly injecting your political opinions is helpful. I won't inject comments about Merkel because they are irrelevant. Let's get out of our trenches and have more constructive dialogue. Will you join me?
For clarity: The contract with ICANN can say that pigs may fly, but that does not change the laws of physics. If anything in the contract or ICANN policies violates applicable law, that part of the contract is null and void, does not apply, can be ignored, has no relevance, etc, etc. BTW: it even says so in the RAA. Maybe you can find the relevant passage yourself...
If you have the law on your side, pound the law. If you have the facts on your side, pound the facts. Since you have neither, you pound the table.
Just because you appear not to like the facts or the laws, they do not become less applicable.
No one has all the facts here and no one is a master of the laws of every nation on this subject. Let's build bridges to build common understanding. Can I count on you?
But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc...
ICANN sets the rules, you get to follow them.
If ICANN sets illegal rules, we get to ignore them. So why set illegal rules in the first place? To trap the unwitting and careless registrars?
You get a voice, we get a voice.
Your voice can demand anything it likes, but if it is not in compliance with the law, it will be ignored. And rightly so.
That's how contracts work. Nope! Contracts do not allow a contracted party to break the law. There is a reason assassination contracts are illegal.
No one is suggesting you break the law. Calm down.
Chuck, this is why we're in trench warfare. And it isn't going to change. Appears so. If one side continues to demand the illegal and the impossible for their own benefit, we will get nowhere. So why not educate yourself on the requirements of current and upcoming privacy regulations and afterwards, we can talk again...
No one is demanding anything illegal.
So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true.
Best, Volker
> On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: > Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois. > > Sent from my iPhone > > On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: > >> I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. >> But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against. >> >> My .02 cents >> >> >> Nathalie >> >> >> On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: >> >> >> On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote: >> > Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free. >> > >> >> But I thought the point of what we were doing was to make some >> proposals for what to mask and how -- basically, that's what >> differential access does. And I also thought we were at the beginning >> of that effort (much as it frustrates me the rate at which we move). >> >> > The question of whether fields are optional or can be "masked" is inherently part of this discussion. >> > >> >> That's just conflating two different things. The first thing is to >> ask whether something should be collected _at all_. Then one can ask, >> if something is collected, who may obtain it and under what >> circumstances. This latter is the "masking" of which you speak. And >> it's all implemented as it currently is because whois is brain-dead. >> So let us not be restricted to the functionality we can get from a >> primitive protocol that had already been extended well beyond its >> design constraints more than 20 years ago. >> >> > To enable third-parties to communicate directly to resolve and troubleshoot problems. >> >> I suggest that's already there. >> >> > To enable third-parties to report abuse or security incidents so they may be resolved. >> >> This too. >> >> > To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news). >> > >> >> I find it impossible to imagine using the whois for this purpose, so >> I'd like a use description for this. Since it's not authenticated or >> authenticatable information anyway, as there are no signatures and so >> on, it seems a pretty poor way to do it. This is partly included in >> the purposes however when we discuss X.509 certificates. >> >> > ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important. >> > >> >> While I strongly agree that the purposes need to be rather wider than >> the domain name industry, I'm uncomfortable with both of the claims of >> quasi-regulatory authority, the notion of the Internet as a commons. >> The root zone is indeed a natural monopoly, though. >> >> Best regards, >> >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> gnso-rds-pdp-wg mailing list >> gnso-rds-pdp-wg@icann.org >> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >> >> >> _______________________________________________ >> gnso-rds-pdp-wg mailing list >> gnso-rds-pdp-wg@icann.org >> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg > > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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.
_______________________________________________ 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 Lisa, Could you refer me to the documents providing for the Exception to the application of a law due to conflict, that was referred to at some point (by teh WG on transition from thin to thick Whois)? Thank you, Nathalie On Thursday, March 23, 2017 11:00 AM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: Sent from my iPhone On Mar 23, 2017, at 09:44, Volker Greimann <vgreimann@key-systems.net> wrote: Whois is the rope with which bad actors hang themselves. Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well. I think maybe its best you let the people who do this work speak for the value of the information. We're using it in criminal investigations and prosecutions. You're just simply taking their money. Believe it or not, bad actors cost us money. We'd love to be able to "not to take their money" as it is a poisoned pill. And we see the whois data used by criminals all the time, when we look at the reports we are sent. Usually it is fake data ripped from some online database or the phone book. So its a baseless allegation that investigators might have expertise in how they use this data? Only domain registrars who have a financial relationship with the criminals know how to use this data? I referred to your last sentence which directly implied that registrars in general and the registrar I am employed with in particular profit from criminals using their service. This is a baseless allegation that could not be farther from the truth, as I have previously explained. That's a rather dramatic misreading. We investigate crimes so I would appreciate due deference to what data is valuable or not. Your role here is providing a service. You don't work with law enforcement to investigate crimes, do you? I have used the law to craft a possible solution but no DP authority has taken your position. Ultimately, that may be the road we have to take if no better solution to provide registrar services legally presents itself, but as I pointed out, that will ultimately serve no one. Registrars will have to raise their fees to incorporate the service, crime fighters and LEAs will have a much more difficult time getting ANY data across borders. Your "solution" would just make your own work a lot harder. I think perhaps deference to my opinion as to what would make MY work harder might be warranted. If you agree, I offer the same deference to you in matters in which your expertise is germane. Deal? You are simply taking the position that if your profits aren't maximized and your costs aren't minimized it is illegal. This position is untenable. Again, I resent you putting words into my mouth. Please do not make statements on my behalf or try to turn your assumptions into a claim of what I am saying. I am saying that anything we come up with will have to be in full compliance with legal requirements. And if there is a cost attached to that solution, that cost will be passed on somewhere, one way or another, not because I want it to but because I know that is the way it works. To which I agree. Let's craft a legal solution the represents the best of what we can offer for all ours (you, me, and everyone else's) interests. I think we can do balance. Will you join me in trying?
You have a contract with ICANN, that contract establishes requirements. Those requirements make it legal. If you believe that, you probably still believe in Trump and other things as well. The above statement is so supendiously wrong, it boggles the mind. You are basically saying that a contract to break the law somehow makes it ok to do so? So if we signed a contract tomorrow to rob the local bank, that absolves us from any guilt?
No one care about your inane political opinions. So I was right? Also good attempt at dodging the argument, but the point I made still stands. No, I just don't think constantly injecting your political opinions is helpful. I won't inject comments about Merkel because they are irrelevant. Let's get out of our trenches and have more constructive dialogue. Will you join me? For clarity: The contract with ICANN can say that pigs may fly, but that does not change the laws of physics. If anything in the contract or ICANN policies violates applicable law, that part of the contract is null and void, does not apply, can be ignored, has no relevance, etc, etc. BTW: it even says so in the RAA. Maybe you can find the relevant passage yourself... If you have the law on your side, pound the law. If you have the facts on your side, pound the facts. Since you have neither, you pound the table. Just because you appear not to like the facts or the laws, they do not become less applicable. No one has all the facts here and no one is a master of the laws of every nation on this subject. Let's build bridges to build common understanding. Can I count on you? But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc... ICANN sets the rules, you get to follow them. If ICANN sets illegal rules, we get to ignore them. So why set illegal rules in the first place? To trap the unwitting and careless registrars? You get a voice, we get a voice. Your voice can demand anything it likes, but if it is not in compliance with the law, it will be ignored. And rightly so. That's how contracts work. Nope! Contracts do not allow a contracted party to break the law. There is a reason assassination contracts are illegal. No one is suggesting you break the law. Calm down. Chuck, this is why we're in trench warfare. And it isn't going to change. Appears so. If one side continues to demand the illegal and the impossible for their own benefit, we will get nowhere. So why not educate yourself on the requirements of current and upcoming privacy regulations and afterwards, we can talk again... No one is demanding anything illegal. So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true. Best, Volker On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois. Sent from my iPhone On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against. My .02 cents Nathalie On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free.
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
The question of whether fields are optional or can be "masked" is inherently part of this discussion.
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news).
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important.
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Nathalie, You can find information on ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law here: https://www.icann.org/resources/pages/whois-privacy-conflicts-procedure-2008.... You will also find a section on the “Additional Key Inputs” page on this PDP WG’s wiki page (https://community.icann.org/display/gTLDRDS/Additional+Key+Inputs) linking to several pages and documents along the lifecycle of this procedure. Also of possible interest is the GNSO Council resolution from last month that confirmed the Council’s non-objection to the final report of an Implementation Advisory Group (IAG) that reviewed the implementation details of the WHOIS conflict with privacy policy: https://gnso.icann.org/en/council/resolutions#201702. We will make sure that the IAG’s final report is added to the relevant section on the “Additional Key Inputs” page of the WG wiki. I hope this helps. Thanks. Amr From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Reply-To: nathalie coupet <nathaliecoupet@yahoo.com> Date: Thursday, March 23, 2017 at 5:08 PM To: Lisa Phifer via Gnso-rds-pdp-purpose <gnso-rds-pdp-purpose@icann.org> Cc: "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi Lisa, Could you refer me to the documents providing for the Exception to the application of a law due to conflict, that was referred to at some point (by teh WG on transition from thin to thick Whois)? Thank you, Nathalie On Thursday, March 23, 2017 11:00 AM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: Sent from my iPhone On Mar 23, 2017, at 09:44, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Whois is the rope with which bad actors hang themselves. Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well. I think maybe its best you let the people who do this work speak for the value of the information. We're using it in criminal investigations and prosecutions. You're just simply taking their money. Believe it or not, bad actors cost us money. We'd love to be able to "not to take their money" as it is a poisoned pill. And we see the whois data used by criminals all the time, when we look at the reports we are sent. Usually it is fake data ripped from some online database or the phone book. So its a baseless allegation that investigators might have expertise in how they use this data? Only domain registrars who have a financial relationship with the criminals know how to use this data? I referred to your last sentence which directly implied that registrars in general and the registrar I am employed with in particular profit from criminals using their service. This is a baseless allegation that could not be farther from the truth, as I have previously explained. That's a rather dramatic misreading. We investigate crimes so I would appreciate due deference to what data is valuable or not. Your role here is providing a service. You don't work with law enforcement to investigate crimes, do you? I have used the law to craft a possible solution but no DP authority has taken your position. Ultimately, that may be the road we have to take if no better solution to provide registrar services legally presents itself, but as I pointed out, that will ultimately serve no one. Registrars will have to raise their fees to incorporate the service, crime fighters and LEAs will have a much more difficult time getting ANY data across borders. Your "solution" would just make your own work a lot harder. I think perhaps deference to my opinion as to what would make MY work harder might be warranted. If you agree, I offer the same deference to you in matters in which your expertise is germane. Deal? You are simply taking the position that if your profits aren't maximized and your costs aren't minimized it is illegal. This position is untenable. Again, I resent you putting words into my mouth. Please do not make statements on my behalf or try to turn your assumptions into a claim of what I am saying. I am saying that anything we come up with will have to be in full compliance with legal requirements. And if there is a cost attached to that solution, that cost will be passed on somewhere, one way or another, not because I want it to but because I know that is the way it works. To which I agree. Let's craft a legal solution the represents the best of what we can offer for all ours (you, me, and everyone else's) interests. I think we can do balance. Will you join me in trying?
You have a contract with ICANN, that contract establishes requirements. Those requirements make it legal. If you believe that, you probably still believe in Trump and other things as well. The above statement is so supendiously wrong, it boggles the mind. You are basically saying that a contract to break the law somehow makes it ok to do so? So if we signed a contract tomorrow to rob the local bank, that absolves us from any guilt?
No one care about your inane political opinions. So I was right? Also good attempt at dodging the argument, but the point I made still stands. No, I just don't think constantly injecting your political opinions is helpful. I won't inject comments about Merkel because they are irrelevant. Let's get out of our trenches and have more constructive dialogue. Will you join me? For clarity: The contract with ICANN can say that pigs may fly, but that does not change the laws of physics. If anything in the contract or ICANN policies violates applicable law, that part of the contract is null and void, does not apply, can be ignored, has no relevance, etc, etc. BTW: it even says so in the RAA. Maybe you can find the relevant passage yourself... If you have the law on your side, pound the law. If you have the facts on your side, pound the facts. Since you have neither, you pound the table. Just because you appear not to like the facts or the laws, they do not become less applicable. No one has all the facts here and no one is a master of the laws of every nation on this subject. Let's build bridges to build common understanding. Can I count on you? But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc... ICANN sets the rules, you get to follow them. If ICANN sets illegal rules, we get to ignore them. So why set illegal rules in the first place? To trap the unwitting and careless registrars? You get a voice, we get a voice. Your voice can demand anything it likes, but if it is not in compliance with the law, it will be ignored. And rightly so. That's how contracts work. Nope! Contracts do not allow a contracted party to break the law. There is a reason assassination contracts are illegal. No one is suggesting you break the law. Calm down. Chuck, this is why we're in trench warfare. And it isn't going to change. Appears so. If one side continues to demand the illegal and the impossible for their own benefit, we will get nowhere. So why not educate yourself on the requirements of current and upcoming privacy regulations and afterwards, we can talk again... No one is demanding anything illegal. So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true. Best, Volker On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois. Sent from my iPhone On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against. My .02 cents Nathalie On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote: On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free.
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
The question of whether fields are optional or can be "masked" is inherently part of this discussion.
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news).
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important.
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> ______________________________ _________________ 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> -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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<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 -- 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
Thanks Amr. It is important for interested parties to know that the trigger for invoking the conflicts procedure has been revised recently. Steve Metalitz Sent with Good (www.good.com) -----Original Message----- From: Amr Elsadr [amr.elsadr@icann.org<mailto:amr.elsadr@icann.org>] Sent: Thursday, March 23, 2017 08:36 AM Pacific Standard Time To: nathalie coupet; Lisa Phifer via Gnso-rds-pdp-purpose Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi Nathalie, You can find information on ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law here: https://www.icann.org/resources/pages/whois-privacy-conflicts-procedure-2008-01-17-en<https://www.icann.org/resources/pages/whois-privacy-conflicts-procedure-2008-01-17-en>. You will also find a section on the “Additional Key Inputs” page on this PDP WG’s wiki page (https://community.icann.org/display/gTLDRDS/Additional+Key+Inputs)<https://community.icann.org/display/gTLDRDS/Additional+Key+Inputs)> linking to several pages and documents along the lifecycle of this procedure. Also of possible interest is the GNSO Council resolution from last month that confirmed the Council’s non-objection to the final report of an Implementation Advisory Group (IAG) that reviewed the implementation details of the WHOIS conflict with privacy policy: https://gnso.icann.org/en/council/resolutions#201702<https://gnso.icann.org/en/council/resolutions#201702>. We will make sure that the IAG’s final report is added to the relevant section on the “Additional Key Inputs” page of the WG wiki. I hope this helps. Thanks. Amr From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Reply-To: nathalie coupet <nathaliecoupet@yahoo.com> Date: Thursday, March 23, 2017 at 5:08 PM To: Lisa Phifer via Gnso-rds-pdp-purpose <gnso-rds-pdp-purpose@icann.org> Cc: "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi Lisa, Could you refer me to the documents providing for the Exception to the application of a law due to conflict, that was referred to at some point (by teh WG on transition from thin to thick Whois)? Thank you, Nathalie On Thursday, March 23, 2017 11:00 AM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: Sent from my iPhone On Mar 23, 2017, at 09:44, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Whois is the rope with which bad actors hang themselves. Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well. I think maybe its best you let the people who do this work speak for the value of the information. We're using it in criminal investigations and prosecutions. You're just simply taking their money. Believe it or not, bad actors cost us money. We'd love to be able to "not to take their money" as it is a poisoned pill. And we see the whois data used by criminals all the time, when we look at the reports we are sent. Usually it is fake data ripped from some online database or the phone book. So its a baseless allegation that investigators might have expertise in how they use this data? Only domain registrars who have a financial relationship with the criminals know how to use this data? I referred to your last sentence which directly implied that registrars in general and the registrar I am employed with in particular profit from criminals using their service. This is a baseless allegation that could not be farther from the truth, as I have previously explained. That's a rather dramatic misreading. We investigate crimes so I would appreciate due deference to what data is valuable or not. Your role here is providing a service. You don't work with law enforcement to investigate crimes, do you? I have used the law to craft a possible solution but no DP authority has taken your position. Ultimately, that may be the road we have to take if no better solution to provide registrar services legally presents itself, but as I pointed out, that will ultimately serve no one. Registrars will have to raise their fees to incorporate the service, crime fighters and LEAs will have a much more difficult time getting ANY data across borders. Your "solution" would just make your own work a lot harder. I think perhaps deference to my opinion as to what would make MY work harder might be warranted. If you agree, I offer the same deference to you in matters in which your expertise is germane. Deal? You are simply taking the position that if your profits aren't maximized and your costs aren't minimized it is illegal. This position is untenable. Again, I resent you putting words into my mouth. Please do not make statements on my behalf or try to turn your assumptions into a claim of what I am saying. I am saying that anything we come up with will have to be in full compliance with legal requirements. And if there is a cost attached to that solution, that cost will be passed on somewhere, one way or another, not because I want it to but because I know that is the way it works. To which I agree. Let's craft a legal solution the represents the best of what we can offer for all ours (you, me, and everyone else's) interests. I think we can do balance. Will you join me in trying?
You have a contract with ICANN, that contract establishes requirements. Those requirements make it legal. If you believe that, you probably still believe in Trump and other things as well. The above statement is so supendiously wrong, it boggles the mind. You are basically saying that a contract to break the law somehow makes it ok to do so? So if we signed a contract tomorrow to rob the local bank, that absolves us from any guilt?
No one care about your inane political opinions. So I was right? Also good attempt at dodging the argument, but the point I made still stands. No, I just don't think constantly injecting your political opinions is helpful. I won't inject comments about Merkel because they are irrelevant. Let's get out of our trenches and have more constructive dialogue. Will you join me? For clarity: The contract with ICANN can say that pigs may fly, but that does not change the laws of physics. If anything in the contract or ICANN policies violates applicable law, that part of the contract is null and void, does not apply, can be ignored, has no relevance, etc, etc. BTW: it even says so in the RAA. Maybe you can find the relevant passage yourself... If you have the law on your side, pound the law. If you have the facts on your side, pound the facts. Since you have neither, you pound the table. Just because you appear not to like the facts or the laws, they do not become less applicable. No one has all the facts here and no one is a master of the laws of every nation on this subject. Let's build bridges to build common understanding. Can I count on you? But we can find criminals faster with it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc... ICANN sets the rules, you get to follow them. If ICANN sets illegal rules, we get to ignore them. So why set illegal rules in the first place? To trap the unwitting and careless registrars? You get a voice, we get a voice. Your voice can demand anything it likes, but if it is not in compliance with the law, it will be ignored. And rightly so. That's how contracts work. Nope! Contracts do not allow a contracted party to break the law. There is a reason assassination contracts are illegal. No one is suggesting you break the law. Calm down. Chuck, this is why we're in trench warfare. And it isn't going to change. Appears so. If one side continues to demand the illegal and the impossible for their own benefit, we will get nowhere. So why not educate yourself on the requirements of current and upcoming privacy regulations and afterwards, we can talk again... No one is demanding anything illegal. So fully standardizing this will probably force some registrars to collect and share far more data than they currently do, and it's unlikely to reduce the data collected by the ones who collect more. Nope, the opposite is true. Best, Volker On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: Excellent suggestion. Perhaps a future action item could be a survey of who various classes of stakeholders use RDS/whois. Sent from my iPhone On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: I have a hard time understanding what very stakeholder wants. If every group of stakeholder could write down how they see the new RDS functioning, just by doing a Venn diagram, we could better understand what we have in common and what we need to foncus on to reduce differences of opinion. But that would require more work from already busy people. I think though, it could give us a more tangible view of what we are up against. My .02 cents Nathalie On Tuesday, March 21, 2017 9:45 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote: On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free.
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
The question of whether fields are optional or can be "masked" is inherently part of this discussion.
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news).
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important.
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> ______________________________ _________________ 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> -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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> -- 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<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>
Thank you! Nathalie On Thursday, March 23, 2017 11:39 AM, Lisa Phifer <lisa@corecom.com> wrote: Nathalie and all, This and other background documents can be found on this page: https://community.icann.org/display/gTLDRDS/Additional+Key+Inputs In this case, see the following -- Procedure for Handling Conflicts with National Laws - GNSO Policy underlying current ICANN Procedure (2006) - ICANN Procedure For Handling WHOIS Conflicts with Privacy Law (2008) - Review of the ICANN Procedure for Handling WHOIS Conflicts with PrivacyLaw (2014) - 2013 RAA'sData Retention Specification Waiver andDiscussion Document (2014) - Final Report on the Implementation Advisory Group Review of ExistingICANN Procedure for Handling Whois Conflicts with Privacy Laws(2016) Best, Lisa At 09:08 AM 3/23/2017, nathalie coupet via gnso-rds-pdp-wg wrote: Hi Lisa, Could you refer me to the documents providing for the Exception to theapplication of a law due to conflict, that was referred to at some point(by teh WG on transition from thin to thick Whois)? Thank you, Nathalie On Thursday, March 23, 2017 11:00AM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org>wrote: Sent from my iPhone On Mar 23, 2017, at 09:44, Volker Greimann<vgreimann@key-systems.net> wrote: Whois is the rope with which bad actors hangthemselves. Maybe dumb bad actors. Savvy bad actors justpopulate whois with data of unknowing third parties, thereby renderingany verification and validation instruments useless and inconveniencingthe affected data subjects as well. I think maybe its best you let the people who do this work speak for thevalue of the information. We're using it in criminal investigationsand prosecutions. You're just simply taking theirmoney. Believe it or not, bad actors cost us money. We'd loveto be able to "not to take their money" as it is a poisonedpill. And we see the whois data used by criminals all the time, when we look atthe reports we are sent. Usually it is fake data ripped from some onlinedatabase or the phone book. So its a baseless allegation that investigators might have expertise inhow they use this data? Only domain registrars who have a financialrelationship with the criminals know how to use this data? Ireferred to your last sentence which directly implied that registrars ingeneral and the registrar I am employed with in particular profit fromcriminals using their service. This is a baseless allegation that couldnot be farther from the truth, as I have previously explained. That's a rather dramatic misreading. We investigate crimes so I wouldappreciate due deference to what data is valuable or not. Your role hereis providing a service. You don't work with law enforcement toinvestigate crimes, do you? I have used the law to craft apossible solution but no DP authority has taken your position. Ultimately, that may be the road we have to take if nobetter solution to provide registrar services legally presents itself,but as I pointed out, that will ultimately serve no one. Registrars willhave to raise their fees to incorporate the service, crime fighters andLEAs will have a much more difficult time getting ANY data acrossborders. Your "solution" would just make your own work a lotharder. I think perhaps deference to my opinion as to what would make MY workharder might be warranted. If you agree, I offer the same deference toyou in matters in which your expertise is germane. Deal? You are simply taking theposition that if your profits aren't maximized and your costs aren'tminimized it is illegal. This position is untenable. Again,I resent you putting words into my mouth. Please do not make statementson my behalf or try to turn your assumptions into a claim of what I amsaying. I am saying that anything we come up with will have to be in fullcompliance with legal requirements. And if there is a cost attached tothat solution, that cost will be passed on somewhere, one way or another,not because I want it to but because I know that is the way itworks. To which I agree. Let's craft a legal solution the represents the best ofwhat we can offer for all ours (you, me, and everyone else's) interests.I think we can do balance. Will you join me in trying?
You have a contract withICANN, that contract establishes requirements. Those requirements make itlegal. If you believe that, you probably still believe in Trump and other thingsas well. The above statement is so supendiously wrong, it boggles themind. You are basically saying that a contract to break the law somehowmakes it ok to do so? So if we signed a contract tomorrow to rob thelocal bank, that absolves us from any guilt?
No one care about your inane political opinions. So I wasright? Also good attempt at dodging the argument, but the point I made stillstands. No, I just don't think constantly injecting your political opinions ishelpful. I won't inject comments about Merkel because they areirrelevant. Let's get out of our trenches and have more constructivedialogue. Will you join me? For clarity: The contract with ICANN can say that pigs may fly, but thatdoes not change the laws of physics. If anything in the contract or ICANNpolicies violates applicable law, that part of the contract is null andvoid, does not apply, can be ignored, has no relevance, etc, etc. BTW: iteven says so in the RAA. Maybe you can find the relevant passageyourself... If you have the law on your side, pound the law. If you have the facts onyour side, pound the facts. Since you have neither, you pound thetable. Just because you appear not to like the factsor the laws, they do not become less applicable. No one has all the facts here and no one is a master of the laws of everynation on this subject. Let's build bridges to build commonunderstanding. Can I count on you? But we can find criminals fasterwith it! - No legal relevance. But we want to contact infringers! - No legal relevance. etc... ICANN sets the rules, you get to follow them. If ICANN setsillegal rules, we get to ignore them. So why set illegal rules in thefirst place? To trap the unwitting and careless registrars? You get a voice, we get a voice. Your voice can demand anything it likes, but if it is not incompliance with the law, it will be ignored. And rightly so. That's how contracts work. Nope! Contracts do not allow a contracted party to break thelaw. There is a reason assassination contracts are illegal. No one is suggesting you break the law. Calm down. Chuck, this is why we're intrench warfare. And it isn't going to change. Appearsso. If one side continues to demand the illegal and the impossible fortheir own benefit, we will get nowhere. So why not educate yourself onthe requirements of current and upcoming privacy regulations andafterwards, we can talk again... No one is demanding anything illegal. So fully standardizing this willprobably force some registrars to collect and share far more data thanthey currently do, and it's unlikely to reduce the data collected by theones who collect more. Nope, the opposite is true. Best, Volker On Tue, Mar 21, 2017 at 10:17 PM, John Bambenek via gnso-rds-pdp-wg<gnso-rds-pdp-wg@icann.org> wrote: - Excellent suggestion. Perhaps a future action item could be asurvey of who various classes of stakeholders use RDS/whois. - Sent from my iPhone - On Mar 21, 2017, at 21:07, nathalie coupet via gnso-rds-pdp-wg<gnso-rds-pdp-wg@icann.org> wrote: - I have a hard time understanding what very stakeholder wants. Ifevery group of stakeholder could write down how they see the new RDSfunctioning, just by doing a Venn diagram, we could better understandwhat we have in common and what we need to foncus on to reducedifferences of opinion. - But that would require more work from already busy people. I thinkthough, it could give us a more tangible view of what we are up against. - My .02 cents - - - Nathalie - On Tuesday, March 21, 2017 9:45PM, Andrew Sullivan<ajs@anvilwalrusden.com> wrote: - On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek viagnso-rds-pdp-wg wrote: - > Except that is not the only approach to the problem nor the onesexclusively used by DP authorities (i.e. Twitter). That is why I askedthe question I did and why I will be lobbying them directly for whoisprivacy for free. - > - But I thought the point of what we were doing was to make some - proposals for what to mask and how -- basically, that's what - differential access does. And I also thought we were at thebeginning - of that effort (much as it frustrates me the rate at which wemove). - > The question of whether fields are optional or can be"masked" is inherently part of this discussion. - > - That's just conflating two different things. The first thing isto - ask whether something should be collected _at all_. Then onecan ask, - if something is collected, who may obtain it and under what - circumstances. This latter is the "masking" of whichyou speak. And - it's all implemented as it currently is because whois isbrain-dead. - So let us not be restricted to the functionality we can get froma - primitive protocol that had already been extended well beyondits - design constraints more than 20 years ago. - > To enable third-parties to communicate directly to resolve andtroubleshoot problems. - I suggest that's already there. - > To enable third-parties to report abuse or security incidents sothey may be resolved. - This too. - > To enable users and entities to have information to adjudicatean entity is who they say they are (for instance phishing, scams, fakenews). - > - I find it impossible to imagine using the whois for this purpose,so - I'd like a use description for this. Since it's notauthenticated or - authenticatable information anyway, as there are no signatures andso - on, it seems a pretty poor way to do it. This is partlyincluded in - the purposes however when we discuss X.509 certificates. - > ICANN isn't just a business to confer domain names. Its aquasi-regulatory body over a "commons" and a natural monopoly.The purposes must be viewed beyond the prism of the mereregistrar-consumer relationship as many interests are relevant and justas important. - > - While I strongly agree that the purposes need to be rather widerthan - the domain name industry, I'm uncomfortable with both of the claimsof - quasi-regulatory authority, the notion of the Internet as acommons. - The root zone is indeed a natural monopoly, though. - Best regards, - A - -- - Andrew Sullivan - ajs@anvilwalrusden.com - ______________________________ _________________ - gnso-rds-pdp-wg mailing list - gnso-rds-pdp-wg@icann.org - https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg - ______________________________ _________________ - gnso-rds-pdp-wg mailing list - gnso-rds-pdp-wg@icann.org - https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg - ______________________________ _________________ - gnso-rds-pdp-wg mailing list - gnso-rds-pdp-wg@icann.org - https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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. _______________________________________________ gnso-rds-pdp-wg mailinglistgnso-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
So its a baseless allegation that investigators might have expertise in how they use this data? Only domain registrars who have a financial relationship with the criminals know how to use this data?
I referred to your last sentence which directly implied that registrars in general and the registrar I am employed with in particular profit from criminals using their service. This is a baseless allegation that could not be farther from the truth, as I have previously explained.
That's a rather dramatic misreading. We investigate crimes so I would appreciate due deference to what data is valuable or not. Your role here is providing a service. You don't work with law enforcement to investigate crimes, do you? Actually, we regularly cooperate with law enforcement agencies that contact us. We see what data they request. We also see all the complaints regarding illegal use of domains registered through us and take appropriate action. So don't try to tell us our only role is to provide a service.
I have used the law to craft a possible solution but no DP authority has taken your position. Ultimately, that may be the road we have to take if no better solution to provide registrar services legally presents itself, but as I pointed out, that will ultimately serve no one. Registrars will have to raise their fees to incorporate the service, crime fighters and LEAs will have a much more difficult time getting ANY data across borders. Your "solution" would just make your own work a lot harder. I think perhaps deference to my opinion as to what would make MY work harder might be warranted. If you agree, I offer the same deference to you in matters in which your expertise is germane. Deal? No deal. Sorry, but you do not get to claim to be the only source of expertise in your line of work.
You are simply taking the position that if your profits aren't maximized and your costs aren't minimized it is illegal. This position is untenable. Again, I resent you putting words into my mouth. Please do not make statements on my behalf or try to turn your assumptions into a claim of what I am saying. I am saying that anything we come up with will have to be in full compliance with legal requirements. And if there is a cost attached to that solution, that cost will be passed on somewhere, one way or another, not because I want it to but because I know that is the way it works. To which I agree. Let's craft a legal solution the represents the best of what we can offer for all ours (you, me, and everyone else's) interests. I think we can do balance. Will you join me in trying?
I am here because I want to find a solution to the problems of current whois on the basis of the proposal of the EWG. That is what our WG has been tasked with. I have no interest in maintaining the status quo as that will soon lead to legal issues. I am for constructive dialogue that advances this work for the benefit of all parties. -- 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 am disappointed that upon asking for respect for my expertise you have chosen again to choose the path of disparagement. I had hoped we could take this time to build bridges and you have used it to burn them. I have offered the olive branch and you have rejected it. So I guess here we are now. Sent from my iPhone
On Mar 23, 2017, at 10:28, Volker Greimann <vgreimann@key-systems.net> wrote:
So its a baseless allegation that investigators might have expertise in how they use this data? Only domain registrars who have a financial relationship with the criminals know how to use this data?
I referred to your last sentence which directly implied that registrars in general and the registrar I am employed with in particular profit from criminals using their service. This is a baseless allegation that could not be farther from the truth, as I have previously explained.
That's a rather dramatic misreading. We investigate crimes so I would appreciate due deference to what data is valuable or not. Your role here is providing a service. You don't work with law enforcement to investigate crimes, do you? Actually, we regularly cooperate with law enforcement agencies that contact us. We see what data they request. We also see all the complaints regarding illegal use of domains registered through us and take appropriate action. So don't try to tell us our only role is to provide a service.
I have used the law to craft a possible solution but no DP authority has taken your position. Ultimately, that may be the road we have to take if no better solution to provide registrar services legally presents itself, but as I pointed out, that will ultimately serve no one. Registrars will have to raise their fees to incorporate the service, crime fighters and LEAs will have a much more difficult time getting ANY data across borders. Your "solution" would just make your own work a lot harder. I think perhaps deference to my opinion as to what would make MY work harder might be warranted. If you agree, I offer the same deference to you in matters in which your expertise is germane. Deal? No deal. Sorry, but you do not get to claim to be the only source of expertise in your line of work.
You are simply taking the position that if your profits aren't maximized and your costs aren't minimized it is illegal. This position is untenable. Again, I resent you putting words into my mouth. Please do not make statements on my behalf or try to turn your assumptions into a claim of what I am saying. I am saying that anything we come up with will have to be in full compliance with legal requirements. And if there is a cost attached to that solution, that cost will be passed on somewhere, one way or another, not because I want it to but because I know that is the way it works. To which I agree. Let's craft a legal solution the represents the best of what we can offer for all ours (you, me, and everyone else's) interests. I think we can do balance. Will you join me in trying?
I am here because I want to find a solution to the problems of current whois on the basis of the proposal of the EWG. That is what our WG has been tasked with. I have no interest in maintaining the status quo as that will soon lead to legal issues. I am for constructive dialogue that advances this work for the benefit of all parties.
-- 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 line. Sent from my iPhone
On Mar 21, 2017, at 20:45, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 03:01:50PM -0500, John Bambenek via gnso-rds-pdp-wg wrote: Except that is not the only approach to the problem nor the ones exclusively used by DP authorities (i.e. Twitter). That is why I asked the question I did and why I will be lobbying them directly for whois privacy for free.
But I thought the point of what we were doing was to make some proposals for what to mask and how -- basically, that's what differential access does. And I also thought we were at the beginning of that effort (much as it frustrates me the rate at which we move).
I guess I am speaking of masking in a broad sense. What do we allow the consumer to mask and on what terms.
The question of whether fields are optional or can be "masked" is inherently part of this discussion.
That's just conflating two different things. The first thing is to ask whether something should be collected _at all_. Then one can ask, if something is collected, who may obtain it and under what circumstances. This latter is the "masking" of which you speak. And it's all implemented as it currently is because whois is brain-dead. So let us not be restricted to the functionality we can get from a primitive protocol that had already been extended well beyond its design constraints more than 20 years ago.
I would disagree on they being separate issues. No matter what technology is created, some things will have to be fully public and some things are subject to debate here. For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
Not in what I saw in the poll.
To enable third-parties to report abuse or security incidents so they may be resolved.
This too.
To enable users and entities to have information to adjudicate an entity is who they say they are (for instance phishing, scams, fake news).
I find it impossible to imagine using the whois for this purpose, so I'd like a use description for this. Since it's not authenticated or authenticatable information anyway, as there are no signatures and so on, it seems a pretty poor way to do it. This is partly included in the purposes however when we discuss X.509 certificates.
It actually happens to me quite frequently. I get an email from X at say y.com. Says they want to contract my services, speak at a conference, investigate an incident. Are they actually a legitimate entity? We've already covered that whois data is unauthenticated and a registrar on this list all but admitted they knowingly ignore fake whois data. But I am not a fair target. I work in investigations and intelligence. So you can send me an email from say citibankcreditcards.com and I'll check the address in whois to compare to a corp registry, or known good domains. I imagine the brand protection investigators could chime in here on their thoughts too. I also develop machine learning tools that proactively find junk data in domains and scores them to protect my customers. Is X person a spammer? Whois privacy protection is a good indicator. Is Y domain used in hacking the DNC registered by Russian intelligence? We can make that assessment because we know how they lie. Z domain was registered 12 hours ago, can email and web traffic from that domain be trusted (no)? X.509 certs are more maliciously pointless. At least registrars don't sell a service to authenticate domain owners. The entire X.509 and CA regime exists for one purpose, to validate the person asking for a cert is who they say they are. That's the service you pay for. And the entire thing is a complete failure whole and entire that instills a false sense of security where there is none. And if you like I can give you validated SSL certs for every domain on this lost to prove it. But again, I do investigations and intelligence for a living and how people lie is very useful to me.
ICANN isn't just a business to confer domain names. Its a quasi-regulatory body over a "commons" and a natural monopoly. The purposes must be viewed beyond the prism of the mere registrar-consumer relationship as many interests are relevant and just as important.
While I strongly agree that the purposes need to be rather wider than the domain name industry, I'm uncomfortable with both of the claims of quasi-regulatory authority, the notion of the Internet as a commons. The root zone is indeed a natural monopoly, though.
I'd be interested in why you say that? How isn't the domain registration regime a commons? Does ICANN not contractually require certain behaviors of various parties?
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
Not this again .... no matter how many times it's repeated it will always remain utter nonsense as a justification/use/need for rds.... WHOIS/RDS is *NOT* in anyway necessary for the 'functioning' of the internet, it is not how dns works, it is not how nameservers are found, it is not used at all in determining the authoritive nameservers. IP to Domain, Domain to IP resolving will work just fine exactly as it does now if whois was just 'turned off' because it does not use whois. Rob
On Wed, Mar 22, 2017 at 03:26:24AM +0000, Rob Golding wrote:
WHOIS/RDS is *NOT* in anyway necessary for the 'functioning' of the internet
The collection of the data through an SRS (which is the back end of the RDS) certainly _is_ required to make the DNS work today. We could have done it differently, of course -- a nasty bit of hackery with SIG(0) and DNS Update might have been good enough for most registries. But that's not what we did, and so collecting the NS data for a given name is something that SRSes do, and therefore the collection of that data falls under this WG's charter. One might think that was a scope mistake, but it's what the charter says. And since we're talking about data collection just now it's not a mistake to talk about nameserver data, no matter how absurd that might seem. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Registrars need to collect authoritative DNS servers from end consumers or it doesn't work. I never said RDS/Whois in that statement. If I buy a domain from GoDaddy and they don't collect auth nameservers and send it to the registry my domain will never ever resolve unless you think this group is empowered to rewrite the RFC completely on how DNS works. Sent from my iPhone On Mar 21, 2017, at 22:26, Rob Golding <rob.golding@astutium.com> wrote:
For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
Not this again .... no matter how many times it's repeated it will always remain utter nonsense as a justification/use/need for rds....
WHOIS/RDS is *NOT* in anyway necessary for the 'functioning' of the internet, it is not how dns works, it is not how nameservers are found, it is not used at all in determining the authoritive nameservers.
IP to Domain, Domain to IP resolving will work just fine exactly as it does now if whois was just 'turned off' because it does not use whois.
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On 2017-03-22 03:38, John Bambenek wrote:
Registrars need to collect authoritative DNS servers from end consumers or it doesn't work.
Yes, for almost all gtlds and cctlds that is the case They're not necessarily shown in a whois, and that in no way stops t'interwebbyfacetweetnet functioning exactly as designed. For example there are no nameservers listed on a current .tel whois for nic.tel yet whois.nic.tel resolves ok Indeed because that data is available through other 'correct' methods, following good-old 3rd-normal-form of db design would say that is a good reason not to have it in rds/whois !
I never said RDS/Whois in that statement.
You mentioned gated access, which we were discussing about in terms of gated access to RDS :) Rob
Sent from my iPhone
On Mar 21, 2017, at 23:05, Rob Golding <rob.golding@astutium.com> wrote:
On 2017-03-22 03:38, John Bambenek wrote: Registrars need to collect authoritative DNS servers from end consumers or it doesn't work.
Yes, for almost all gtlds and cctlds that is the case
They're not necessarily shown in a whois, and that in no way stops t'interwebbyfacetweetnet functioning exactly as designed. For example there are no nameservers listed on a current .tel whois for nic.tel yet whois.nic.tel resolves ok
Indeed because that data is available through other 'correct' methods, following good-old 3rd-normal-form of db design would say that is a good reason not to have it in rds/whois !
I never said RDS/Whois in that statement.
You mentioned gated access, which we were discussing about in terms of gated access to RDS :)
Fair enough, I could have been more precise
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On 22 Mar 2017, at 11:26 am, Rob Golding <rob.golding@astutium.com> wrote:
For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
Not this again .... no matter how many times it's repeated it will always remain utter nonsense as a justification/use/need for rds....
WHOIS/RDS is *NOT* in anyway necessary for the 'functioning' of the internet, it is not how dns works, it is not how nameservers are found, it is not used at all in determining the authoritive nameservers.
IP to Domain, Domain to IP resolving will work just fine exactly as it does now if whois was just 'turned off' because it does not use whois.
Isn’t that assuming that IP:domain is a one to one correspondence, which is not at all true of the modern internet? David
Isn’t that assuming that IP:domain is a one to one correspondence, which is not at all true of the modern internet?
That's the "job" of namesevers/resolvers to handle, which they do already. Yes, that data will be public (I hope no-one is suggesting we redesign how dns works). No, that data does not need to be in "whois" as it's not "whois" that is used to do it now. Rob
On Tue, Mar 21, 2017 at 09:16:45PM -0500, John Bambenek wrote:
I guess I am speaking of masking in a broad sense. What do we allow the consumer to mask and on what terms.
Right. I thought that answering that question was part of our job.
I would disagree on they being separate issues. No matter what technology is created, some things will have to be fully public and some things are subject to debate here.
What to collect and what can be disclosed are obviously _related_ issues, but they are separable and I think usefully separated here. We'll never get anywhere unless we break these things into manageable chunks.
For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
I don't think anyone has been arguing that nameservers ought to be private data, and they clearly need to be collected in order to feed the DNS in order to make it work. But that particular example isn't really an interesting one, is it? Indeed, as I think my lengthy email demonstrated, I find it pretty hard to suggest that any "thin" data is private; it all certainly needs to be collected to make the system work at all. The same arguments are obviously harder to make for people's names and addresses, so there's more to do in that case.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
Not in what I saw in the poll.
We discussed this bit at some length last week, and my sense of the room was that everyone agreed that is a purpose.
But I am not a fair target. I work in investigations and intelligence. So you can send me an email from say citibankcreditcards.com and I'll check the address in whois to compare to a corp registry, or known good domains. I imagine the brand protection investigators could chime in here on their thoughts too.
I think what you're saying is that you use the whois data as one piece of input to heuristics that allow you to develop a view about the legitimacy of the domain name. I thought your original wording was a little too positivist about the value of the data, but if it's instead input to some heuristic mechanism I withdraw that objection.
X.509 certs are more maliciously pointless.
I'm certainly not going to attempt to argue that the PKI has worked as intended. But in terms of an ordinary user's ability to do anything with information, they're what people really use. (Yes, to their peril.)
I'd be interested in why you say that? How isn't the domain registration regime a commons? Does ICANN not contractually require certain behaviors of various parties?
I think that's rather off topic here, but if you want I'll follow up off-list. A -- Andrew Sullivan ajs@anvilwalrusden.com
Inline Sent from my iPhone
On Mar 21, 2017, at 22:31, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 09:16:45PM -0500, John Bambenek wrote:
I guess I am speaking of masking in a broad sense. What do we allow the consumer to mask and on what terms.
Right. I thought that answering that question was part of our job.
I agree. I postulated one possible answer.
I would disagree on they being separate issues. No matter what technology is created, some things will have to be fully public and some things are subject to debate here.
What to collect and what can be disclosed are obviously _related_ issues, but they are separable and I think usefully separated here. We'll never get anywhere unless we break these things into manageable chunks.
If we are driving this by regulatory burden of DP authorities the fact that they will be dramatically less concerned if the consumer has a true choice is highly relevant up front.
For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
I don't think anyone has been arguing that nameservers ought to be private data, and they clearly need to be collected in order to feed the DNS in order to make it work. But that particular example isn't really an interesting one, is it? Indeed, as I think my lengthy email demonstrated, I find it pretty hard to suggest that any "thin" data is private; it all certainly needs to be collected to make the system work at all. The same arguments are obviously harder to make for people's names and addresses, so there's more to do in that case.
It was an example to prove the point.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
Not in what I saw in the poll.
We discussed this bit at some length last week, and my sense of the room was that everyone agreed that is a purpose.
Not every stakeholder has an unlimited travel budget to hop on a plane for these events. I had a baby last week. We are doing this by email because global consensus cant be solely a function of who is in a room at one specific event.
But I am not a fair target. I work in investigations and intelligence. So you can send me an email from say citibankcreditcards.com and I'll check the address in whois to compare to a corp registry, or known good domains. I imagine the brand protection investigators could chime in here on their thoughts too.
I think what you're saying is that you use the whois data as one piece of input to heuristics that allow you to develop a view about the legitimacy of the domain name. I thought your original wording was a little too positivist about the value of the data, but if it's instead input to some heuristic mechanism I withdraw that objection.
X.509 certs are more maliciously pointless.
I'm certainly not going to attempt to argue that the PKI has worked as intended. But in terms of an ordinary user's ability to do anything with information, they're what people really use. (Yes, to their peril.)
Fair point. Probably it was an aside to my contempt of the ssl mafia anyway. Let's encrypt is the only honest broker there.
I'd be interested in why you say that? How isn't the domain registration regime a commons? Does ICANN not contractually require certain behaviors of various parties?
I think that's rather off topic here, but if you want I'll follow up off-list.
Please do.
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
If we are driving this by regulatory burden of DP authorities the fact that they will be dramatically less concerned if the consumer has a true choice is highly relevant up front. If consumers have a “true choice” over how their data is used — that is, a genuine choice, obtained through a very clear and specific statement of consent, with granular consent obtained for distinct processing operations, along with ongoing control over how their data is used, including the right to revoke previously granted consent — that would be one thing. There would still be questions to be answered around the over-collection of data, cross-jurisdictional transfers, etc. But if granting ‘consent’ becomes a precondition of using a service, it is inherently unfair and not a “true choice”. You don’t need to be a Data Protection Commissioner to see that. If you are doing things with my personal data that I don’t understand or want, or you make it difficult for me to control how my own data is used or shared, you are eroding my trust in your organisation. Best wishes, Ayden Férdeline [linkedin.com/in/ferdeline](http://www.linkedin.com/in/ferdeline) -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Local Time: 22 March 2017 3:42 AM UTC Time: 22 March 2017 03:42 From: gnso-rds-pdp-wg@icann.org To: Andrew Sullivan <ajs@anvilwalrusden.com> gnso-rds-pdp-wg@icann.org Inline Sent from my iPhone
On Mar 21, 2017, at 22:31, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 09:16:45PM -0500, John Bambenek wrote:
I guess I am speaking of masking in a broad sense. What do we allow the consumer to mask and on what terms.
Right. I thought that answering that question was part of our job.
I agree. I postulated one possible answer.
I would disagree on they being separate issues. No matter what technology is created, some things will have to be fully public and some things are subject to debate here.
What to collect and what can be disclosed are obviously _related_ issues, but they are separable and I think usefully separated here. We'll never get anywhere unless we break these things into manageable chunks.
If we are driving this by regulatory burden of DP authorities the fact that they will be dramatically less concerned if the consumer has a true choice is highly relevant up front.
For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
I don't think anyone has been arguing that nameservers ought to be private data, and they clearly need to be collected in order to feed the DNS in order to make it work. But that particular example isn't really an interesting one, is it? Indeed, as I think my lengthy email demonstrated, I find it pretty hard to suggest that any "thin" data is private; it all certainly needs to be collected to make the system work at all. The same arguments are obviously harder to make for people's names and addresses, so there's more to do in that case.
It was an example to prove the point.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
Not in what I saw in the poll.
We discussed this bit at some length last week, and my sense of the room was that everyone agreed that is a purpose.
Not every stakeholder has an unlimited travel budget to hop on a plane for these events. I had a baby last week. We are doing this by email because global consensus cant be solely a function of who is in a room at one specific event.
But I am not a fair target. I work in investigations and intelligence. So you can send me an email from say citibankcreditcards.com and I'll check the address in whois to compare to a corp registry, or known good domains. I imagine the brand protection investigators could chime in here on their thoughts too.
I think what you're saying is that you use the whois data as one piece of input to heuristics that allow you to develop a view about the legitimacy of the domain name. I thought your original wording was a little too positivist about the value of the data, but if it's instead input to some heuristic mechanism I withdraw that objection.
X.509 certs are more maliciously pointless.
I'm certainly not going to attempt to argue that the PKI has worked as intended. But in terms of an ordinary user's ability to do anything with information, they're what people really use. (Yes, to their peril.)
Fair point. Probably it was an aside to my contempt of the ssl mafia anyway. Let's encrypt is the only honest broker there.
I'd be interested in why you say that? How isn't the domain registration regime a commons? Does ICANN not contractually require certain behaviors of various parties?
I think that's rather off topic here, but if you want I'll follow up off-list.
Please do.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
This is exactly my point. This control can be given to consumers for free and it SHOULD be free. That solves almost everything we are talking about. Sent from my iPhone On Mar 22, 2017, at 05:30, Ayden Férdeline <icann@ferdeline.com> wrote:
If we are driving this by regulatory burden of DP authorities the fact that they will be dramatically less concerned if the consumer has a true choice is highly relevant up front.
If consumers have a “true choice” over how their data is used — that is, a genuine choice, obtained through a very clear and specific statement of consent, with granular consent obtained for distinct processing operations, along with ongoing control over how their data is used, including the right to revoke previously granted consent — that would be one thing. There would still be questions to be answered around the over-collection of data, cross-jurisdictional transfers, etc. But if granting ‘consent’ becomes a precondition of using a service, it is inherently unfair and not a “true choice”. You don’t need to be a Data Protection Commissioner to see that. If you are doing things with my personal data that I don’t understand or want, or you make it difficult for me to control how my own data is used or shared, you are eroding my trust in your organisation.
Best wishes,
Ayden Férdeline linkedin.com/in/ferdeline
-------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Local Time: 22 March 2017 3:42 AM UTC Time: 22 March 2017 03:42 From: gnso-rds-pdp-wg@icann.org To: Andrew Sullivan <ajs@anvilwalrusden.com> gnso-rds-pdp-wg@icann.org
Inline
Sent from my iPhone
On Mar 21, 2017, at 22:31, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 09:16:45PM -0500, John Bambenek wrote:
I guess I am speaking of masking in a broad sense. What do we allow the consumer to mask and on what terms.
Right. I thought that answering that question was part of our job.
I agree. I postulated one possible answer.
I would disagree on they being separate issues. No matter what technology is created, some things will have to be fully public and some things are subject to debate here.
What to collect and what can be disclosed are obviously _related_ issues, but they are separable and I think usefully separated here. We'll never get anywhere unless we break these things into manageable chunks.
If we are driving this by regulatory burden of DP authorities the fact that they will be dramatically less concerned if the consumer has a true choice is highly relevant up front.
For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
I don't think anyone has been arguing that nameservers ought to be private data, and they clearly need to be collected in order to feed the DNS in order to make it work. But that particular example isn't really an interesting one, is it? Indeed, as I think my lengthy email demonstrated, I find it pretty hard to suggest that any "thin" data is private; it all certainly needs to be collected to make the system work at all. The same arguments are obviously harder to make for people's names and addresses, so there's more to do in that case.
It was an example to prove the point.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
Not in what I saw in the poll.
We discussed this bit at some length last week, and my sense of the room was that everyone agreed that is a purpose.
Not every stakeholder has an unlimited travel budget to hop on a plane for these events. I had a baby last week. We are doing this by email because global consensus cant be solely a function of who is in a room at one specific event.
But I am not a fair target. I work in investigations and intelligence. So you can send me an email from say citibankcreditcards.com and I'll check the address in whois to compare to a corp registry, or known good domains. I imagine the brand protection investigators could chime in here on their thoughts too.
I think what you're saying is that you use the whois data as one piece of input to heuristics that allow you to develop a view about the legitimacy of the domain name. I thought your original wording was a little too positivist about the value of the data, but if it's instead input to some heuristic mechanism I withdraw that objection.
X.509 certs are more maliciously pointless.
I'm certainly not going to attempt to argue that the PKI has worked as intended. But in terms of an ordinary user's ability to do anything with information, they're what people really use. (Yes, to their peril.)
Fair point. Probably it was an aside to my contempt of the ssl mafia anyway. Let's encrypt is the only honest broker there.
I'd be interested in why you say that? How isn't the domain registration regime a commons? Does ICANN not contractually require certain behaviors of various parties?
I think that's rather off topic here, but if you want I'll follow up off-list.
Please do.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Even where consent is obtained, there should still be a genuine and legitimate reason for collecting and processing the data, and data should be collected and processed with no unwarranted impact on the data subject. My understanding of the principles underpinning data protection laws in general is that the collection and processing of data must always be weighed against the potential harm to the individual’s rights and interests. I hope we are agreed on this point as well. Best wishes, Ayden Férdeline [linkedin.com/in/ferdeline](http://www.linkedin.com/in/ferdeline) -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Local Time: 22 March 2017 1:48 PM UTC Time: 22 March 2017 13:48 From: jcb@bambenekconsulting.com To: Ayden Férdeline <icann@ferdeline.com> Andrew Sullivan <ajs@anvilwalrusden.com>, gnso-rds-pdp-wg@icann.org This is exactly my point. This control can be given to consumers for free and it SHOULD be free. That solves almost everything we are talking about. Sent from my iPhone On Mar 22, 2017, at 05:30, Ayden Férdeline <icann@ferdeline.com> wrote: If we are driving this by regulatory burden of DP authorities the fact that they will be dramatically less concerned if the consumer has a true choice is highly relevant up front. If consumers have a “true choice” over how their data is used — that is, a genuine choice, obtained through a very clear and specific statement of consent, with granular consent obtained for distinct processing operations, along with ongoing control over how their data is used, including the right to revoke previously granted consent — that would be one thing. There would still be questions to be answered around the over-collection of data, cross-jurisdictional transfers, etc. But if granting ‘consent’ becomes a precondition of using a service, it is inherently unfair and not a “true choice”. You don’t need to be a Data Protection Commissioner to see that. If you are doing things with my personal data that I don’t understand or want, or you make it difficult for me to control how my own data is used or shared, you are eroding my trust in your organisation. Best wishes, Ayden Férdeline [linkedin.com/in/ferdeline](http://www.linkedin.com/in/ferdeline) -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Local Time: 22 March 2017 3:42 AM UTC Time: 22 March 2017 03:42 From: gnso-rds-pdp-wg@icann.org To: Andrew Sullivan <ajs@anvilwalrusden.com> gnso-rds-pdp-wg@icann.org Inline Sent from my iPhone
On Mar 21, 2017, at 22:31, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 09:16:45PM -0500, John Bambenek wrote:
I guess I am speaking of masking in a broad sense. What do we allow the consumer to mask and on what terms.
Right. I thought that answering that question was part of our job.
I agree. I postulated one possible answer.
I would disagree on they being separate issues. No matter what technology is created, some things will have to be fully public and some things are subject to debate here.
What to collect and what can be disclosed are obviously _related_ issues, but they are separable and I think usefully separated here. We'll never get anywhere unless we break these things into manageable chunks.
If we are driving this by regulatory burden of DP authorities the fact that they will be dramatically less concerned if the consumer has a true choice is highly relevant up front.
For instance, if we don't make authoritative nameservers fully public without gates, we break the internet. I don't mean that as hyperbole, I mean no internet except for the savants who can us IP addresses for everything.
I don't think anyone has been arguing that nameservers ought to be private data, and they clearly need to be collected in order to feed the DNS in order to make it work. But that particular example isn't really an interesting one, is it? Indeed, as I think my lengthy email demonstrated, I find it pretty hard to suggest that any "thin" data is private; it all certainly needs to be collected to make the system work at all. The same arguments are obviously harder to make for people's names and addresses, so there's more to do in that case.
It was an example to prove the point.
To enable third-parties to communicate directly to resolve and troubleshoot problems.
I suggest that's already there.
Not in what I saw in the poll.
We discussed this bit at some length last week, and my sense of the room was that everyone agreed that is a purpose.
Not every stakeholder has an unlimited travel budget to hop on a plane for these events. I had a baby last week. We are doing this by email because global consensus cant be solely a function of who is in a room at one specific event.
But I am not a fair target. I work in investigations and intelligence. So you can send me an email from say citibankcreditcards.com and I'll check the address in whois to compare to a corp registry, or known good domains. I imagine the brand protection investigators could chime in here on their thoughts too.
I think what you're saying is that you use the whois data as one piece of input to heuristics that allow you to develop a view about the legitimacy of the domain name. I thought your original wording was a little too positivist about the value of the data, but if it's instead input to some heuristic mechanism I withdraw that objection.
X.509 certs are more maliciously pointless.
I'm certainly not going to attempt to argue that the PKI has worked as intended. But in terms of an ordinary user's ability to do anything with information, they're what people really use. (Yes, to their peril.)
Fair point. Probably it was an aside to my contempt of the ssl mafia anyway. Let's encrypt is the only honest broker there.
I'd be interested in why you say that? How isn't the domain registration regime a commons? Does ICANN not contractually require certain behaviors of various parties?
I think that's rather off topic here, but if you want I'll follow up off-list.
Please do.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi all, As a Registrar providing P/P services, it is easy to jump to the idea providing it for free makes a lot of problems go away. That being said, I agree with Stephanie in a sense we are getting ahead of ourselves. Also, we need to consider that the PPSAI IRT is currently drafting, and that outcome might change things, on how "free" things are going to be. Theo On 21-3-2017 20:49, Stephanie Perrin wrote:
Indeed, the WHOIS disclosure instrument may be the thing that sticks in everybody's mind, but it is not the first place to start in addressing a comprehensive approach to RDS privacy. First you have to address why you are collecting each data element. Is the core purpose justifiable and proportionate? etc, we spent an hour on it with Mr. Canatacci and we are not done yet....
Yes, privacy proxy services have been the stop gap over the years. The data is still being collected without a clear statement of purpose, disclosed in a variety of ways that may not pass muster, retained in violation of at least EU law and likely others, data subject access and disclosure rights inadequately addressed......
Lets wait till we get our answers to the questions before we start discussing possible solutions. I think we are jumping ahead quite a bit.
Stephanie Perrin
On 2017-03-21 15:18, allison nixon wrote:
I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well.
On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question.
Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced.
Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world.
It isn't an ancillary question. Its the fundamental one.
Sent from my iPhone
> On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>" <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote: > >> On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: >> I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this. > > I don't see how. The experts last week were quite clear that the > first question is about collection, and our PDP is chartered to talk > about that too, so we have to discuss whether some of this data should > be collected at all, and if so by whom. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> > _______________________________________________ > 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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
If access to whois is going to be closed off from the general public, there isn't going to be any point in charging money for whois privacy anyways. On Tue, Mar 21, 2017 at 4:08 PM, theo geurts <gtheo@xs4all.nl> wrote:
Hi all,
As a Registrar providing P/P services, it is easy to jump to the idea providing it for free makes a lot of problems go away.
That being said, I agree with Stephanie in a sense we are getting ahead of ourselves. Also, we need to consider that the PPSAI IRT is currently drafting, and that outcome might change things, on how "free" things are going to be.
Theo
On 21-3-2017 20:49, Stephanie Perrin wrote:
Indeed, the WHOIS disclosure instrument may be the thing that sticks in everybody's mind, but it is not the first place to start in addressing a comprehensive approach to RDS privacy. First you have to address why you are collecting each data element. Is the core purpose justifiable and proportionate? etc, we spent an hour on it with Mr. Canatacci and we are not done yet....
Yes, privacy proxy services have been the stop gap over the years. The data is still being collected without a clear statement of purpose, disclosed in a variety of ways that may not pass muster, retained in violation of at least EU law and likely others, data subject access and disclosure rights inadequately addressed......
Lets wait till we get our answers to the questions before we start discussing possible solutions. I think we are jumping ahead quite a bit.
Stephanie Perrin
On 2017-03-21 15:18, allison nixon wrote:
I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well.
On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question.
Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced.
Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world.
It isn't an ancillary question. Its the fundamental one.
Sent from my iPhone
On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com" < ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this.
I don't see how. The experts last week were quite clear that the first question is about collection, and our PDP is chartered to talk about that too, so we have to discuss whether some of this data should be collected at all, and if so by whom.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
If access to whois is going to be closed off from the general public, there isn't going to be any point in charging money for whois privacy anyways.
You think spammers and scammers wont find a way to get access to the data and illegally share it just because it becomes gated ? Rob
I think gating or stopping whois won't impede criminals one iota. It will impede researchers, defenders and those who try to make the internet safe and will be rife with unintended consequences. Sent from my iPhone On Mar 21, 2017, at 20:03, Rob Golding <rob.golding@astutium.com> wrote:
If access to whois is going to be closed off from the general public, there isn't going to be any point in charging money for whois privacy anyways.
You think spammers and scammers wont find a way to get access to the data and illegally share it just because it becomes gated ?
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
+1 whois is imperfect, like any system. like RDS will be if it comes to pass. RDS will just be imperfect in a different way. i don't agree with some of the rhetoric here on Whois being totally useless or horribly broken. but that ship may have sailed. we'll need to understand and consider the unintended consequences of any new system, in our design process. as a member of the Business Constituency, there are RDS-related issues related to security and stability and trust in the DNS, issues built into the Mission of ICANN, that are important to me and to other members of the BC, that are beyond the privacy issues that in my initial read seem to dominate the conversation of this working group. I look forward to bringing those to bear as I have the time and attention to do so. On Tue, Mar 21, 2017 at 6:15 PM, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
I think gating or stopping whois won't impede criminals one iota. It will impede researchers, defenders and those who try to make the internet safe and will be rife with unintended consequences.
Sent from my iPhone
On Mar 21, 2017, at 20:03, Rob Golding <rob.golding@astutium.com> wrote:
If access to whois is going to be closed off from the general public, there isn't going to be any point in charging money for whois privacy anyways.
You think spammers and scammers wont find a way to get access to the data and illegally share it just because it becomes gated ?
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
+1 We might also want to make an economic impact analysis on the implementation of any new RDS. Sent from my iPhone
On Mar 22, 2017, at 12:26 AM, Chen, Tim <tim@domaintools.com> wrote:
+1 whois is imperfect, like any system. like RDS will be if it comes to pass. RDS will just be imperfect in a different way. i don't agree with some of the rhetoric here on Whois being totally useless or horribly broken. but that ship may have sailed. we'll need to understand and consider the unintended consequences of any new system, in our design process. as a member of the Business Constituency, there are RDS-related issues related to security and stability and trust in the DNS, issues built into the Mission of ICANN, that are important to me and to other members of the BC, that are beyond the privacy issues that in my initial read seem to dominate the conversation of this working group. I look forward to bringing those to bear as I have the time and attention to do so.
On Tue, Mar 21, 2017 at 6:15 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: I think gating or stopping whois won't impede criminals one iota. It will impede researchers, defenders and those who try to make the internet safe and will be rife with unintended consequences.
Sent from my iPhone
On Mar 21, 2017, at 20:03, Rob Golding <rob.golding@astutium.com> wrote:
If access to whois is going to be closed off from the general public, there isn't going to be any point in charging money for whois privacy anyways.
You think spammers and scammers wont find a way to get access to the data and illegally share it just because it becomes gated ?
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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
It is certainly my strong intention that security and stability and trust issues are addressed thoroughly. However, I think many of those issues are going to be hard to address properly in Phase 1, which deals with fundamental requirements. We can, of course, specify that security and stability and resiliency etc are among the fundamental requirements (and please, if you feel there are additional specific requirements there do bring them up). But for the most part, it is hard to fully address those issues until we have answered some fairly basic design questions (e.g. centralised or federated, cached or uncached, etc) that we will not discuss until phase 2. I also agree that whatever we produce will not be perfect. But I think if we carefully articulate the principles we have been working on and the architecture behind it, and create an architecture that allows for more flexibility in its operation than whois, then a new RDS may be far more amenable to useful ongoing analysis and incremental improvement than whois. With careful design, we may be able to produce a system that is not just less broken than whois, but also easier to fix by future policy processes. (even just the switch to RDAP goes a long way in this direction for some classes of problem) David
On 22 Mar 2017, at 12:26 pm, Chen, Tim <tim@domaintools.com> wrote:
+1 whois is imperfect, like any system. like RDS will be if it comes to pass. RDS will just be imperfect in a different way. i don't agree with some of the rhetoric here on Whois being totally useless or horribly broken. but that ship may have sailed. we'll need to understand and consider the unintended consequences of any new system, in our design process. as a member of the Business Constituency, there are RDS-related issues related to security and stability and trust in the DNS, issues built into the Mission of ICANN, that are important to me and to other members of the BC, that are beyond the privacy issues that in my initial read seem to dominate the conversation of this working group. I look forward to bringing those to bear as I have the time and attention to do so.
On Tue, Mar 21, 2017 at 6:15 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote: I think gating or stopping whois won't impede criminals one iota. It will impede researchers, defenders and those who try to make the internet safe and will be rife with unintended consequences.
Sent from my iPhone
On Mar 21, 2017, at 20:03, Rob Golding <rob.golding@astutium.com <mailto:rob.golding@astutium.com>> wrote:
If access to whois is going to be closed off from the general public, there isn't going to be any point in charging money for whois privacy anyways.
You think spammers and scammers wont find a way to get access to the data and illegally share it just because it becomes gated ?
Rob _______________________________________________ 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
Good points David. Don't you think also that architecture will have to happen later as well. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of David Cake Sent: Wednesday, March 22, 2017 1:28 PM To: Chen, Tim <tim@domaintools.com> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" It is certainly my strong intention that security and stability and trust issues are addressed thoroughly. However, I think many of those issues are going to be hard to address properly in Phase 1, which deals with fundamental requirements. We can, of course, specify that security and stability and resiliency etc are among the fundamental requirements (and please, if you feel there are additional specific requirements there do bring them up). But for the most part, it is hard to fully address those issues until we have answered some fairly basic design questions (e.g. centralised or federated, cached or uncached, etc) that we will not discuss until phase 2. I also agree that whatever we produce will not be perfect. But I think if we carefully articulate the principles we have been working on and the architecture behind it, and create an architecture that allows for more flexibility in its operation than whois, then a new RDS may be far more amenable to useful ongoing analysis and incremental improvement than whois. With careful design, we may be able to produce a system that is not just less broken than whois, but also easier to fix by future policy processes. (even just the switch to RDAP goes a long way in this direction for some classes of problem) David On 22 Mar 2017, at 12:26 pm, Chen, Tim <tim@domaintools.com<mailto:tim@domaintools.com>> wrote: +1 whois is imperfect, like any system. like RDS will be if it comes to pass. RDS will just be imperfect in a different way. i don't agree with some of the rhetoric here on Whois being totally useless or horribly broken. but that ship may have sailed. we'll need to understand and consider the unintended consequences of any new system, in our design process. as a member of the Business Constituency, there are RDS-related issues related to security and stability and trust in the DNS, issues built into the Mission of ICANN, that are important to me and to other members of the BC, that are beyond the privacy issues that in my initial read seem to dominate the conversation of this working group. I look forward to bringing those to bear as I have the time and attention to do so. On Tue, Mar 21, 2017 at 6:15 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: I think gating or stopping whois won't impede criminals one iota. It will impede researchers, defenders and those who try to make the internet safe and will be rife with unintended consequences. Sent from my iPhone On Mar 21, 2017, at 20:03, Rob Golding <rob.golding@astutium.com<mailto:rob.golding@astutium.com>> wrote: >> If access to whois is going to be closed off from the general public, >> there isn't going to be any point in charging money for whois privacy >> anyways. > > You think spammers and scammers wont find a way to get access to the data and illegally share it just because it becomes gated ? > > Rob > _______________________________________________ > 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
I agree with Stephanie strongly here. Free privacy services and similar might make a lot of the practical design issues go away, or might not, But I think that is an issue for Phase 2, in which we construct what a new RDS looks like (presuming we conclude that one is needed). Phase 1 concentrates on fundamental requirements, and knowing which data elements we collect and why is necessary, even if that data is not generally made available to the public. Ant this will impact data protection law even if the data that is collected and retained is not widely accessible. Even if we decided that certain data was only accessible with a warrant, we would still need to justify collecting it. Regards David
On 22 Mar 2017, at 3:49 am, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote:
Indeed, the WHOIS disclosure instrument may be the thing that sticks in everybody's mind, but it is not the first place to start in addressing a comprehensive approach to RDS privacy. First you have to address why you are collecting each data element. Is the core purpose justifiable and proportionate? etc, we spent an hour on it with Mr. Canatacci and we are not done yet....
Yes, privacy proxy services have been the stop gap over the years. The data is still being collected without a clear statement of purpose, disclosed in a variety of ways that may not pass muster, retained in violation of at least EU law and likely others, data subject access and disclosure rights inadequately addressed......
Lets wait till we get our answers to the questions before we start discussing possible solutions. I think we are jumping ahead quite a bit.
Stephanie Perrin
On 2017-03-21 15:18, allison nixon wrote:
I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well.
On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote: And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question.
Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced.
Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world.
It isn't an ancillary question. Its the fundamental one.
Sent from my iPhone
On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>" <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this.
I don't see how. The experts last week were quite clear that the first question is about collection, and our PDP is chartered to talk about that too, so we have to discuss whether some of this data should be collected at all, and if so by whom.
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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
The legal review previously discussed seemed pretty clear. What data protection law requires changes greatly if data elements are optional and/or can be masked. Facebook doesn't have to consider every piece of information it collects and each field because all of them are optional. We very clearly DO need to consider whether fields are optional and/or they can be masked if we are going to consider data protection laws as a requirement. For instance, we can't say DP laws say we don't need phone number and can't collect it if we aren't considering consent and whether its an option or requirement. Sent from my iPhone
On Mar 22, 2017, at 04:02, David Cake <dave@davecake.net> wrote:
I agree with Stephanie strongly here. Free privacy services and similar might make a lot of the practical design issues go away, or might not, But I think that is an issue for Phase 2, in which we construct what a new RDS looks like (presuming we conclude that one is needed).
Phase 1 concentrates on fundamental requirements, and knowing which data elements we collect and why is necessary, even if that data is not generally made available to the public. Ant this will impact data protection law even if the data that is collected and retained is not widely accessible. Even if we decided that certain data was only accessible with a warrant, we would still need to justify collecting it.
Regards
David
On 22 Mar 2017, at 3:49 am, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote:
Indeed, the WHOIS disclosure instrument may be the thing that sticks in everybody's mind, but it is not the first place to start in addressing a comprehensive approach to RDS privacy. First you have to address why you are collecting each data element. Is the core purpose justifiable and proportionate? etc, we spent an hour on it with Mr. Canatacci and we are not done yet....
Yes, privacy proxy services have been the stop gap over the years. The data is still being collected without a clear statement of purpose, disclosed in a variety of ways that may not pass muster, retained in violation of at least EU law and likely others, data subject access and disclosure rights inadequately addressed......
Lets wait till we get our answers to the questions before we start discussing possible solutions. I think we are jumping ahead quite a bit.
Stephanie Perrin
On 2017-03-21 15:18, allison nixon wrote: I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well.
On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question.
Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced.
Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world.
It isn't an ancillary question. Its the fundamental one.
Sent from my iPhone
On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com" <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this.
I don't see how. The experts last week were quite clear that the first question is about collection, and our PDP is chartered to talk about that too, so we have to discuss whether some of this data should be collected at all, and if so by whom.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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 legal review previously discussed seemed pretty clear. What data protection law requires changes greatly if data elements are optional and/or can be masked. Facebook doesn't have to consider every piece of information it collects and each field because all of them are optional. Yes, it is different when data elements are truly optional and data subjects provide their explicit, informed consent for their personally-identifiable information to be collected and processed by known entities. However, consent is not a magic bullet. We will still need to address the point raised last week - that we separate what data is collected from discussions around how data is processed or released - and we will need to discuss how consent can inappropriately legitimise processing restricted by law, and the cross-border transfers of data in the absence of adequate safeguards. Meaningful consent also entails the right to revoke that consent; the right to erasure. For instance, we can't say DP laws say we don't need phone number and can't collect it if we aren't considering consent and whether its an option or requirement. As a general rule, I would think that if one is reasonably confident that a data subject would not grant their consent for their data to be collected or processed in a certain way, that should be a warning sign to reconsider whether that data should really be collected or processed in the first place… Best wishes, Ayden Férdeline [linkedin.com/in/ferdeline](http://www.linkedin.com/in/ferdeline) -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Local Time: 22 March 2017 1:46 PM UTC Time: 22 March 2017 13:46 From: gnso-rds-pdp-wg@icann.org To: David Cake <dave@davecake.net> gnso-rds-pdp-wg@icann.org The legal review previously discussed seemed pretty clear. What data protection law requires changes greatly if data elements are optional and/or can be masked. Facebook doesn't have to consider every piece of information it collects and each field because all of them are optional. We very clearly DO need to consider whether fields are optional and/or they can be masked if we are going to consider data protection laws as a requirement. For instance, we can't say DP laws say we don't need phone number and can't collect it if we aren't considering consent and whether its an option or requirement. Sent from my iPhone On Mar 22, 2017, at 04:02, David Cake <dave@davecake.net> wrote: I agree with Stephanie strongly here. Free privacy services and similar might make a lot of the practical design issues go away, or might not, But I think that is an issue for Phase 2, in which we construct what a new RDS looks like (presuming we conclude that one is needed). Phase 1 concentrates on fundamental requirements, and knowing which data elements we collect and why is necessary, even if that data is not generally made available to the public. Ant this will impact data protection law even if the data that is collected and retained is not widely accessible. Even if we decided that certain data was only accessible with a warrant, we would still need to justify collecting it. Regards David On 22 Mar 2017, at 3:49 am, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote: Indeed, the WHOIS disclosure instrument may be the thing that sticks in everybody's mind, but it is not the first place to start in addressing a comprehensive approach to RDS privacy. First you have to address why you are collecting each data element. Is the core purpose justifiable and proportionate? etc, we spent an hour on it with Mr. Canatacci and we are not done yet.... Yes, privacy proxy services have been the stop gap over the years. The data is still being collected without a clear statement of purpose, disclosed in a variety of ways that may not pass muster, retained in violation of at least EU law and likely others, data subject access and disclosure rights inadequately addressed...... Lets wait till we get our answers to the questions before we start discussing possible solutions. I think we are jumping ahead quite a bit. Stephanie Perrin On 2017-03-21 15:18, allison nixon wrote: I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well. On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question. Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced. Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world. It isn't an ancillary question. Its the fundamental one. Sent from my iPhone
On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com" <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this.
I don't see how. The experts last week were quite clear that the first question is about collection, and our PDP is chartered to talk about that too, so we have to discuss whether some of this data should be collected at all, and if so by whom.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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
Sent from my iPhone On Mar 22, 2017, at 09:14, Ayden Férdeline <icann@ferdeline.com> wrote:
The legal review previously discussed seemed pretty clear. What data protection law requires changes greatly if data elements are optional and/or can be masked.
Facebook doesn't have to consider every piece of information it collects and each field because all of them are optional.
Yes, it is different when data elements are truly optional and data subjects provide their explicit, informed consent for their personally-identifiable information to be collected and processed by known entities.
However, consent is not a magic bullet. We will still need to address the point raised last week - that we separate what data is collected from discussions around how data is processed or released - and we will need to discuss how consent can inappropriately legitimise processing restricted by law, and the cross-border transfers of data in the absence of adequate safeguards. Meaningful consent also entails the right to revoke that consent; the right to erasure.
For instance, we can't say DP laws say we don't need phone number and can't collect it if we aren't considering consent and whether its an option or requirement.
As a general rule, I would think that if one is reasonably confident that a data subject would not grant their consent for their data to be collected or processed in a certain way, that should be a warning sign to reconsider whether that data should really be collected or processed in the first place…
But some WOULD publish it and that's the point. I have no problem with my corp number on my domain records because people have called me to resolve issues. Making most of the fields optional/maskable means we don't have to adopt a one-size fits all approach.
Best wishes,
Ayden Férdeline linkedin.com/in/ferdeline
-------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Local Time: 22 March 2017 1:46 PM UTC Time: 22 March 2017 13:46 From: gnso-rds-pdp-wg@icann.org To: David Cake <dave@davecake.net> gnso-rds-pdp-wg@icann.org
The legal review previously discussed seemed pretty clear. What data protection law requires changes greatly if data elements are optional and/or can be masked.
Facebook doesn't have to consider every piece of information it collects and each field because all of them are optional.
We very clearly DO need to consider whether fields are optional and/or they can be masked if we are going to consider data protection laws as a requirement.
For instance, we can't say DP laws say we don't need phone number and can't collect it if we aren't considering consent and whether its an option or requirement.
Sent from my iPhone
On Mar 22, 2017, at 04:02, David Cake <dave@davecake.net> wrote: I agree with Stephanie strongly here. Free privacy services and similar might make a lot of the practical design issues go away, or might not, But I think that is an issue for Phase 2, in which we construct what a new RDS looks like (presuming we conclude that one is needed).
Phase 1 concentrates on fundamental requirements, and knowing which data elements we collect and why is necessary, even if that data is not generally made available to the public. Ant this will impact data protection law even if the data that is collected and retained is not widely accessible. Even if we decided that certain data was only accessible with a warrant, we would still need to justify collecting it.
Regards
David
On 22 Mar 2017, at 3:49 am, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote:
Indeed, the WHOIS disclosure instrument may be the thing that sticks in everybody's mind, but it is not the first place to start in addressing a comprehensive approach to RDS privacy. First you have to address why you are collecting each data element. Is the core purpose justifiable and proportionate? etc, we spent an hour on it with Mr. Canatacci and we are not done yet....
Yes, privacy proxy services have been the stop gap over the years. The data is still being collected without a clear statement of purpose, disclosed in a variety of ways that may not pass muster, retained in violation of at least EU law and likely others, data subject access and disclosure rights inadequately addressed......
Lets wait till we get our answers to the questions before we start discussing possible solutions. I think we are jumping ahead quite a bit.
Stephanie Perrin
On 2017-03-21 15:18, allison nixon wrote: I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well.
On Tue, Mar 21, 2017 at 3:06 PM, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
And part of the "if so" includes whether the individual chooses to protect it in some free privacy regime. It's the same question.
Its why Twitter can exist. If you post publicly knowing you are doing so and having a true choice, then privacy issues become greatly reduced.
Here we have (1) you MUST provide "all this stuff" and (2) you MUST pay extra or we broadcast it to the world.
It isn't an ancillary question. Its the fundamental one.
Sent from my iPhone
> On Mar 21, 2017, at 13:55, "ajs@anvilwalrusden.com" <ajs@anvilwalrusden.com> wrote: > >> On Tue, Mar 21, 2017 at 01:22:18PM -0500, John Bambenek wrote: >> I think we should also discuss at a higher level that if privacy services were free from the registrars if that would largely resolve all of this. > > I don't see how. The experts last week were quite clear that the > first question is about collection, and our PDP is chartered to talk > about that too, so we have to discuss whether some of this data should > be collected at all, and if so by whom. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
_________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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
On Wed, Mar 22, 2017 at 09:30:37AM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Making most of the fields optional/maskable means we don't have to adopt a one-size fits all approach.
But there's a big difference between "optional" and "maskable". Data that isn't collected can't be disclosed, at all, ever, to anyone, because the collector doesn't have it. It cannot be delivered in response to a subpoena. It cannot be leaked due to attacks on the database. It cannot be subject of "just this once" requests from law enforcement or identity thieves doing social engineering or creeps who want to spy on their old girl/boyfriend. Data that is masked or otherwise controlled in disclosure is still there for the taking; we're just arguing about the conditions. And that's why we're talking about data collection first. A -- Andrew Sullivan ajs@anvilwalrusden.com
Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. Sent from my iPhone
On Mar 22, 2017, at 09:56, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 09:30:37AM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Making most of the fields optional/maskable means we don't have to adopt a one-size fits all approach.
But there's a big difference between "optional" and "maskable". Data that isn't collected can't be disclosed, at all, ever, to anyone, because the collector doesn't have it. It cannot be delivered in response to a subpoena. It cannot be leaked due to attacks on the database. It cannot be subject of "just this once" requests from law enforcement or identity thieves doing social engineering or creeps who want to spy on their old girl/boyfriend.
Data that is masked or otherwise controlled in disclosure is still there for the taking; we're just arguing about the conditions.
And that's why we're talking about data collection first.
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
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote:
Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up. I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript *Follow LegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | *Blog <http://blog.legitscript.com>* | Google+ <https://plus.google.com/112436813474708014933/posts> On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Other than the clown part ;-), we share similar concerns to John with respect to civil and criminal investigative efforts generally, and those efforts we undertake on behalf of rights owners. From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of John Horton Sent: Wednesday, March 22, 2017 12:33 PM To: nathalie coupet <nathaliecoupet@yahoo.com> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript [Image removed by sender.] Follow LegitScript: LinkedIn<http://www.linkedin.com/company/legitscript-com> | Facebook<https://www.facebook.com/LegitScript> | Twitter<https://twitter.com/legitscript> | Blog<http://blog.legitscript.com> | Google+<https://plus.google.com/112436813474708014933/posts> [Image removed by sender.][Image removed by sender.] On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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, On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:
My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers.
Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But,
In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
this does not follow. Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.) This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support. Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again. On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:
My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers.
Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But,
In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
this does not follow.
Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.)
This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support.
Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
What system are you referring to Allison? Are you saying that RDAP is not workable? Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of allison nixon Sent: Thursday, March 23, 2017 4:01 AM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail") This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again. On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote: Hi, On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:
My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers.
Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But,
In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
this does not follow. Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.) This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support. Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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 -- _________________________________ Note to self: Pillage BEFORE burning.
No, im referring to this token idea. And really any gated system, i am quite suspicious of, if the gatekeepers will demonstrate a fundamental lack of understanding of how whois is useful here and now. Considering the prevalent attitudes I've seen on this list, the gatekeepers will likely be people who think keeping falsified whois data private is more important than anything else. It shows either a lack of care or some measure of ignorance as to larger realities relating to losses and even privacy itself. I think very few people who work with whois for investigations know what the actual prevalent attitudes are within this group. If they lose a sane way to make whois based decisions, they are not going to tolerate it. On Mar 23, 2017 4:20 AM, "Gomes, Chuck" <cgomes@verisign.com> wrote:
What system are you referring to Allison? Are you saying that RDAP is not workable?
Chuck
*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org] *On Behalf Of *allison nixon *Sent:* Thursday, March 23, 2017 4:01 AM *To:* Andrew Sullivan <ajs@anvilwalrusden.com> *Cc:* RDS PDP WG <gnso-rds-pdp-wg@icann.org> *Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail")
This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again.
On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:
My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers.
Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But,
In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
this does not follow.
Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.)
This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support.
Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
_________________________________ Note to self: Pillage BEFORE burning.
Allison, Have you reviewed the EWG Report? If not, I encourage you to do so. A large number of experts believe it can work. If we decide to recommend gated access for some data elements and for some parties, it will be up to us to develop policy and implementation procedures and Phases 2 & 3 regarding gate keepers so it is way too early to assume who the gate keepers will be. Chuck From: allison nixon [mailto:elsakoo@gmail.com] Sent: Thursday, March 23, 2017 4:50 AM To: Gomes, Chuck <cgomes@verisign.com> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org>; Andrew Sullivan <ajs@anvilwalrusden.com> Subject: [EXTERNAL] RE: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail") No, im referring to this token idea. And really any gated system, i am quite suspicious of, if the gatekeepers will demonstrate a fundamental lack of understanding of how whois is useful here and now. Considering the prevalent attitudes I've seen on this list, the gatekeepers will likely be people who think keeping falsified whois data private is more important than anything else. It shows either a lack of care or some measure of ignorance as to larger realities relating to losses and even privacy itself. I think very few people who work with whois for investigations know what the actual prevalent attitudes are within this group. If they lose a sane way to make whois based decisions, they are not going to tolerate it. On Mar 23, 2017 4:20 AM, "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: What system are you referring to Allison? Are you saying that RDAP is not workable? 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<mailto:gnso-rds-pdp-wg-bounces@icann.org>] On Behalf Of allison nixon Sent: Thursday, March 23, 2017 4:01 AM To: Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail") This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again. On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote: Hi, On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote: > My biggest fear > is that in the monitoring that companies like mine do for banks, payment > providers, e-commerce companies, etc. that helps determine whether a > merchant is who they say they are, and whether they are engaged in other > bad activity (i.e., laundering money) will be unable to obtain access to > the Whois records we need in order to preserve the integrity of the > payments system, protect payment providers from risk, and derivatively > protect consumers. Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But, > In other words, my fear is that we'll lose access to > Whois records, which we need for that purpose. this does not follow. Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.) This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support. Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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 -- _________________________________ Note to self: Pillage BEFORE burning.
Allison, who do you think the gatekeepers are? In the system I am designing, client identity and query purpose can be assigned and confirmed by entities within specific communities of interest. As one example, an entity like the FBI would be responsible for managing the identity credentials for people who claim to be affiliated with the FBI. Keepers of data would then make access control decisions based on whatever policies this group decides are appropriate for people affiliated with the FBI. I have code running in a lab environment right now that demonstrates that this approach really does work. Scott On Mar 23, 2017, at 4:49 AM, allison nixon <elsakoo@gmail.com<mailto:elsakoo@gmail.com>> wrote: No, im referring to this token idea. And really any gated system, i am quite suspicious of, if the gatekeepers will demonstrate a fundamental lack of understanding of how whois is useful here and now. Considering the prevalent attitudes I've seen on this list, the gatekeepers will likely be people who think keeping falsified whois data private is more important than anything else. It shows either a lack of care or some measure of ignorance as to larger realities relating to losses and even privacy itself. I think very few people who work with whois for investigations know what the actual prevalent attitudes are within this group. If they lose a sane way to make whois based decisions, they are not going to tolerate it. On Mar 23, 2017 4:20 AM, "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: What system are you referring to Allison? Are you saying that RDAP is not workable? 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<mailto:gnso-rds-pdp-wg-bounces@icann.org>] On Behalf Of allison nixon Sent: Thursday, March 23, 2017 4:01 AM To: Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail") This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again. On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote: Hi, On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:
My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers.
Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But,
In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
this does not follow. Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.) This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support. Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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 -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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
The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work. Also how will the need for historical whois be fulfilled? The registrars do not maintain that and massive automated querying and redistribution of query results must happen. I don't know where this EWG report is, and it's not in my email so please let me know where it is. I will read it. Also, this gated access reminds me of how we treat personal data in the United States. We sign over our personal data to companies that promise to keep it private* *but they will share with "authorized third parties". The end result is that every interested party has a copy of my personal data anyways! it's worse than if I was just told it was public. I would have at least been more careful. So we are supposed to consider this whois data as private, but under any workable gated access scheme, tens of thousands of people and scripts are going to access this allegedly "private" data, where they will often use it in activities some of which result in publishing or sharing whois data. Potential victims of spam and harassment are going to over-disclose if they are told they can trust this system's "privacy" when the reality is the opposite. Informed consent is impossible and abusers do work at banks and security companies. And I am no expert in european privacy law but i think it would frown on such a system that assures people of the privacy of data it's collecting and then releases it to thousands of people abroad, to use in insecure scripts, with $? funding to vet the people or detect abuse. Maybe barbed wire is safer than padded corners. On Thu, Mar 23, 2017 at 7:21 AM, Hollenbeck, Scott <shollenbeck@verisign.com
wrote:
Allison, who do you think the gatekeepers are? In the system I am designing, client identity and query purpose can be assigned and confirmed by entities within specific communities of interest. As one example, an entity like the FBI would be responsible for managing the identity credentials for people who claim to be affiliated with the FBI. Keepers of data would then make access control decisions based on whatever policies this group decides are appropriate for people affiliated with the FBI. I have code running in a lab environment right now that demonstrates that this approach really does work.
Scott
On Mar 23, 2017, at 4:49 AM, allison nixon <elsakoo@gmail.com> wrote:
No, im referring to this token idea. And really any gated system, i am quite suspicious of, if the gatekeepers will demonstrate a fundamental lack of understanding of how whois is useful here and now.
Considering the prevalent attitudes I've seen on this list, the gatekeepers will likely be people who think keeping falsified whois data private is more important than anything else. It shows either a lack of care or some measure of ignorance as to larger realities relating to losses and even privacy itself.
I think very few people who work with whois for investigations know what the actual prevalent attitudes are within this group. If they lose a sane way to make whois based decisions, they are not going to tolerate it.
On Mar 23, 2017 4:20 AM, "Gomes, Chuck" <cgomes@verisign.com> wrote:
What system are you referring to Allison? Are you saying that RDAP is not workable?
Chuck
*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounce s@icann.org] *On Behalf Of *allison nixon *Sent:* Thursday, March 23, 2017 4:01 AM *To:* Andrew Sullivan <ajs@anvilwalrusden.com> *Cc:* RDS PDP WG <gnso-rds-pdp-wg@icann.org> *Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail")
This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again.
On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:
My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers.
Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But,
In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
this does not follow.
Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.)
This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support.
Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
_________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
Allison, you can find the Final EWG Report here: https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf. As a reminder, all relevant background documents have been collected here: https://community.icann.org/x/QIxlAw. Best regards, Marika From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of allison nixon <elsakoo@gmail.com> Date: Thursday, March 23, 2017 at 07:08 To: "Hollenbeck, Scott" <shollenbeck@verisign.com> Cc: "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail") The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work. Also how will the need for historical whois be fulfilled? The registrars do not maintain that and massive automated querying and redistribution of query results must happen. I don't know where this EWG report is, and it's not in my email so please let me know where it is. I will read it. Also, this gated access reminds me of how we treat personal data in the United States. We sign over our personal data to companies that promise to keep it private* *but they will share with "authorized third parties". The end result is that every interested party has a copy of my personal data anyways! it's worse than if I was just told it was public. I would have at least been more careful. So we are supposed to consider this whois data as private, but under any workable gated access scheme, tens of thousands of people and scripts are going to access this allegedly "private" data, where they will often use it in activities some of which result in publishing or sharing whois data. Potential victims of spam and harassment are going to over-disclose if they are told they can trust this system's "privacy" when the reality is the opposite. Informed consent is impossible and abusers do work at banks and security companies. And I am no expert in european privacy law but i think it would frown on such a system that assures people of the privacy of data it's collecting and then releases it to thousands of people abroad, to use in insecure scripts, with $? funding to vet the people or detect abuse. Maybe barbed wire is safer than padded corners. On Thu, Mar 23, 2017 at 7:21 AM, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote: Allison, who do you think the gatekeepers are? In the system I am designing, client identity and query purpose can be assigned and confirmed by entities within specific communities of interest. As one example, an entity like the FBI would be responsible for managing the identity credentials for people who claim to be affiliated with the FBI. Keepers of data would then make access control decisions based on whatever policies this group decides are appropriate for people affiliated with the FBI. I have code running in a lab environment right now that demonstrates that this approach really does work. Scott On Mar 23, 2017, at 4:49 AM, allison nixon <elsakoo@gmail.com<mailto:elsakoo@gmail.com>> wrote: No, im referring to this token idea. And really any gated system, i am quite suspicious of, if the gatekeepers will demonstrate a fundamental lack of understanding of how whois is useful here and now. Considering the prevalent attitudes I've seen on this list, the gatekeepers will likely be people who think keeping falsified whois data private is more important than anything else. It shows either a lack of care or some measure of ignorance as to larger realities relating to losses and even privacy itself. I think very few people who work with whois for investigations know what the actual prevalent attitudes are within this group. If they lose a sane way to make whois based decisions, they are not going to tolerate it. On Mar 23, 2017 4:20 AM, "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: What system are you referring to Allison? Are you saying that RDAP is not workable? 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<mailto:gnso-rds-pdp-wg-bounces@icann.org>] On Behalf Of allison nixon Sent: Thursday, March 23, 2017 4:01 AM To: Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail") This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again. On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote: Hi, On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:
My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers.
Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But,
In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
this does not follow. Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.) This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support. Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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 -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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 -- _________________________________ Note to self: Pillage BEFORE burning.
Who says we need a Whois Archive? The GDRP have explicitly a section about the right to be forgotten, that will say all records deleted! The way f.ex Domaintools operate today are not in the terms of a lot of whois providers conditions and in some cases illegal -- 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
On 23 Mar 2017, at 14:08, allison nixon <elsakoo@gmail.com> wrote:
The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work.
Also how will the need for historical whois be fulfilled? The registrars do not maintain that and massive automated querying and redistribution of query results must happen.
I don't know where this EWG report is, and it's not in my email so please let me know where it is. I will read it.
Also, this gated access reminds me of how we treat personal data in the United States. We sign over our personal data to companies that promise to keep it private*
*but they will share with "authorized third parties". The end result is that every interested party has a copy of my personal data anyways! it's worse than if I was just told it was public. I would have at least been more careful.
So we are supposed to consider this whois data as private, but under any workable gated access scheme, tens of thousands of people and scripts are going to access this allegedly "private" data, where they will often use it in activities some of which result in publishing or sharing whois data. Potential victims of spam and harassment are going to over-disclose if they are told they can trust this system's "privacy" when the reality is the opposite. Informed consent is impossible and abusers do work at banks and security companies.
And I am no expert in european privacy law but i think it would frown on such a system that assures people of the privacy of data it's collecting and then releases it to thousands of people abroad, to use in insecure scripts, with $? funding to vet the people or detect abuse.
Maybe barbed wire is safer than padded corners.
On Thu, Mar 23, 2017 at 7:21 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote: Allison, who do you think the gatekeepers are? In the system I am designing, client identity and query purpose can be assigned and confirmed by entities within specific communities of interest. As one example, an entity like the FBI would be responsible for managing the identity credentials for people who claim to be affiliated with the FBI. Keepers of data would then make access control decisions based on whatever policies this group decides are appropriate for people affiliated with the FBI. I have code running in a lab environment right now that demonstrates that this approach really does work.
Scott
On Mar 23, 2017, at 4:49 AM, allison nixon <elsakoo@gmail.com> wrote:
No, im referring to this token idea. And really any gated system, i am quite suspicious of, if the gatekeepers will demonstrate a fundamental lack of understanding of how whois is useful here and now.
Considering the prevalent attitudes I've seen on this list, the gatekeepers will likely be people who think keeping falsified whois data private is more important than anything else. It shows either a lack of care or some measure of ignorance as to larger realities relating to losses and even privacy itself.
I think very few people who work with whois for investigations know what the actual prevalent attitudes are within this group. If they lose a sane way to make whois based decisions, they are not going to tolerate it.
On Mar 23, 2017 4:20 AM, "Gomes, Chuck" <cgomes@verisign.com> wrote: What system are you referring to Allison? Are you saying that RDAP is not workable?
Chuck
From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of allison nixon Sent: Thursday, March 23, 2017 4:01 AM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] "access to whois" vs supporting a service (was Re: a suggestion for "purpose in detail")
This suggested system is not workable because the daily use of whois does not conceptually fit within that framework. Several of us who work with whois on a daily basis have already described use cases that are made impossible by that system, so there's no need to go into the same details all over again.
On Wed, Mar 22, 2017 at 1:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Wed, Mar 22, 2017 at 09:33:22AM -0700, John Horton wrote:
My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers.
Modulo the inclusion of "Whois" in the above, that all seems reasonable. What you are saying is that you need a mechanism by which you can create risk analyses with respect to some domain name. But,
In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
this does not follow.
Consider, for instance, that RDAP works via http(s), and that we have several kinds of authentication and authorization mechanisms related to https, and such things can be federated. It is a short hop from that knowledge to understanding that someone(s) could operate a service that authenticates service providers like you, using tokens provided by the to-be-evaluated domain names. A payment provider or whatever, when offering service to a customer, could obtain from that customer a token of consent allowing it to obtain the relevant data from the registries and registrars in question. That token could then be provided to the authorization service, which would then authenticate your request to the RDAP servers and they could provide you the data you request. This is by no means an impossible task -- every time you apply for insurance online or log into a payment provider via Google or Facebook or Amazon, you're doing this. This is a technique that is already deployed all over the Internet where real money is involved, so I fail to see how it could not be used in our case. (In addition, you may not actually need the particulars of an individual -- it might be enough for you to be able to tell whether the domain and people behind it are related in some important ways to some other domain. But we're getting ahead of ourselves in the use case description here.)
This is also why separating the collection of data from questions about display and so on is necessary: we need to understand as a group the compelling use cases that the RDS data can support. I agree that reputation-of-vendor systems are among those uses, and that we ought therefore to include support of such things in what we think we want the system to be able to support.
Of course, all of this does represent some cost to you -- your existing service would need to change to reflect the new business logic and access rules and mechanisms and so on. But I don't think this WG has so far accepted, "But that's how we do it now," as a legitimate purpose.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
_________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi, On Thu, Mar 23, 2017 at 09:08:59AM -0400, allison nixon wrote:
The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work.
I would encourage you to read Scott's messages on this a little more carefully, because I don't think that he's claiming he is covering those costs. What he is doing is demonstrating that the technology for different groups of people to be authenticated by various providers is available, already widely deployed in other parts of the Internet, and applicable to this case. That technology was heretofore unavailable for RDS the way it was for other things, because the historic RDS relies on the ancient whois protocol -- a protocol designed for a world where it was literally possible to get a list, on paper, of every single person who was connected to the Internet. (Some people in this effort have reported to me that they still have old copies lying around.) If your argument is instead, "But we don't have to pay the overhead of authentiction and authorization today, so it should remain that way forever," then I think you are going to have to do a better job arguing for that position. Because to me it is plainly absurd. The world has changed partly because the Internet has changed a great deal. Indeed, the very fact that the Internet can be instrumental in fraud in ways that it certainly could not have been instrumental in 1982 (when RFC 812 was published) suggests to me that appropriate authorization and authentication protocols around the RDS ought to have been embraced -- by law enforcement and others -- quite a long time ago. We ought to be ashamed it has taken us this long, when even Google is concerned about leaking this kind of data.
Also how will the need for historical whois be fulfilled?
This is in part an excellent question because it is not plain that all "historical whois" services are actually ok under existing policy. But of course, this WG is in a position to specify retention periods about data as part of the collection policies that we were working on. RDAP could easily work to provide a picture of something at some time in the past, assuming that the data is available. Whether the data ought to be is a different question, and one we should discuss rather than assume. There is a cost to be paid for collecting, keeping, and ensuring appropriate authorization in the disclosure of data. The existing practices externalize some of those costs onto the individuals whose data is being collected. I recognize that it might not be convenient to have those costs borne by the people who want access, but one of the things markets are good at is allocating resources according to how much value something brings. Perhaps if people had to endure the costs of their desire for access to the data, they would do a better job evaluating the balance of costs versus benefits.
Also, this gated access reminds me of how we treat personal data in the United States.
Speaking as a reluctant citizen of the US, I am sorry to say that US personal data protection is no sort of standard worth emulating. I believe it is only a matter of time before the legal system catches up with the frankly negligent handling of personal data in the US, and that the costs of insurance and liability will get to the point where corporations will get better at it. Even the USG has had major breaches of its databases. In my opinion, those breaches were made easier because the USG it collects too much, saves too much, and handles that collected stuff in a way that is too convenient to those who like to have all the data hanging around in the service of the security state. Peter Wayner's _Translucent Databases_ provides an excellent discussion of the general issues, and is not too long; it came out in 2002 and was hardly at the cutting edge of these discussions even then. I am not sure why the ICANN community has taken 15 years to get with the program, but I think this WG needs to find a way to do so. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
I must say I am overwhelmed by the scope of this task. Can this WG really take on governments and challenge their practices? If so, I think I'll need a drink first. (Not really). Nathalie On Thursday, March 23, 2017 12:21 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: Hi, On Thu, Mar 23, 2017 at 09:08:59AM -0400, allison nixon wrote:
The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work.
I would encourage you to read Scott's messages on this a little more carefully, because I don't think that he's claiming he is covering those costs. What he is doing is demonstrating that the technology for different groups of people to be authenticated by various providers is available, already widely deployed in other parts of the Internet, and applicable to this case. That technology was heretofore unavailable for RDS the way it was for other things, because the historic RDS relies on the ancient whois protocol -- a protocol designed for a world where it was literally possible to get a list, on paper, of every single person who was connected to the Internet. (Some people in this effort have reported to me that they still have old copies lying around.) If your argument is instead, "But we don't have to pay the overhead of authentiction and authorization today, so it should remain that way forever," then I think you are going to have to do a better job arguing for that position. Because to me it is plainly absurd. The world has changed partly because the Internet has changed a great deal. Indeed, the very fact that the Internet can be instrumental in fraud in ways that it certainly could not have been instrumental in 1982 (when RFC 812 was published) suggests to me that appropriate authorization and authentication protocols around the RDS ought to have been embraced -- by law enforcement and others -- quite a long time ago. We ought to be ashamed it has taken us this long, when even Google is concerned about leaking this kind of data.
Also how will the need for historical whois be fulfilled?
This is in part an excellent question because it is not plain that all "historical whois" services are actually ok under existing policy. But of course, this WG is in a position to specify retention periods about data as part of the collection policies that we were working on. RDAP could easily work to provide a picture of something at some time in the past, assuming that the data is available. Whether the data ought to be is a different question, and one we should discuss rather than assume. There is a cost to be paid for collecting, keeping, and ensuring appropriate authorization in the disclosure of data. The existing practices externalize some of those costs onto the individuals whose data is being collected. I recognize that it might not be convenient to have those costs borne by the people who want access, but one of the things markets are good at is allocating resources according to how much value something brings. Perhaps if people had to endure the costs of their desire for access to the data, they would do a better job evaluating the balance of costs versus benefits.
Also, this gated access reminds me of how we treat personal data in the United States.
Speaking as a reluctant citizen of the US, I am sorry to say that US personal data protection is no sort of standard worth emulating. I believe it is only a matter of time before the legal system catches up with the frankly negligent handling of personal data in the US, and that the costs of insurance and liability will get to the point where corporations will get better at it. Even the USG has had major breaches of its databases. In my opinion, those breaches were made easier because the USG it collects too much, saves too much, and handles that collected stuff in a way that is too convenient to those who like to have all the data hanging around in the service of the security state. Peter Wayner's _Translucent Databases_ provides an excellent discussion of the general issues, and is not too long; it came out in 2002 and was hardly at the cutting edge of these discussions even then. I am not sure why the ICANN community has taken 15 years to get with the program, but I think this WG needs to find a way to do so. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Take on is a strong way of putting it. Public policy is about balancing of interests. DP authorities know that. So I intend to use my expertise to show them the best way to solve the problem. I don't expect the entire WG to fall in line. I intend to work with governments directly on that. Sent from my iPhone
On Mar 23, 2017, at 11:47, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
I must say I am overwhelmed by the scope of this task. Can this WG really take on governments and challenge their practices? If so, I think I'll need a drink first. (Not really).
Nathalie
On Thursday, March 23, 2017 12:21 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Thu, Mar 23, 2017 at 09:08:59AM -0400, allison nixon wrote:
The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work.
I would encourage you to read Scott's messages on this a little more carefully, because I don't think that he's claiming he is covering those costs. What he is doing is demonstrating that the technology for different groups of people to be authenticated by various providers is available, already widely deployed in other parts of the Internet, and applicable to this case. That technology was heretofore unavailable for RDS the way it was for other things, because the historic RDS relies on the ancient whois protocol -- a protocol designed for a world where it was literally possible to get a list, on paper, of every single person who was connected to the Internet. (Some people in this effort have reported to me that they still have old copies lying around.)
If your argument is instead, "But we don't have to pay the overhead of authentiction and authorization today, so it should remain that way forever," then I think you are going to have to do a better job arguing for that position. Because to me it is plainly absurd. The world has changed partly because the Internet has changed a great deal. Indeed, the very fact that the Internet can be instrumental in fraud in ways that it certainly could not have been instrumental in 1982 (when RFC 812 was published) suggests to me that appropriate authorization and authentication protocols around the RDS ought to have been embraced -- by law enforcement and others -- quite a long time ago. We ought to be ashamed it has taken us this long, when even Google is concerned about leaking this kind of data.
Also how will the need for historical whois be fulfilled?
This is in part an excellent question because it is not plain that all "historical whois" services are actually ok under existing policy. But of course, this WG is in a position to specify retention periods about data as part of the collection policies that we were working on. RDAP could easily work to provide a picture of something at some time in the past, assuming that the data is available. Whether the data ought to be is a different question, and one we should discuss rather than assume. There is a cost to be paid for collecting, keeping, and ensuring appropriate authorization in the disclosure of data. The existing practices externalize some of those costs onto the individuals whose data is being collected. I recognize that it might not be convenient to have those costs borne by the people who want access, but one of the things markets are good at is allocating resources according to how much value something brings. Perhaps if people had to endure the costs of their desire for access to the data, they would do a better job evaluating the balance of costs versus benefits.
Also, this gated access reminds me of how we treat personal data in the United States.
Speaking as a reluctant citizen of the US, I am sorry to say that US personal data protection is no sort of standard worth emulating. I believe it is only a matter of time before the legal system catches up with the frankly negligent handling of personal data in the US, and that the costs of insurance and liability will get to the point where corporations will get better at it.
Even the USG has had major breaches of its databases. In my opinion, those breaches were made easier because the USG it collects too much, saves too much, and handles that collected stuff in a way that is too convenient to those who like to have all the data hanging around in the service of the security state. Peter Wayner's _Translucent Databases_ provides an excellent discussion of the general issues, and is not too long; it came out in 2002 and was hardly at the cutting edge of these discussions even then. I am not sure why the ICANN community has taken 15 years to get with the program, but I think this WG needs to find a way to do so.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi John, I also think this is the way to go. There is clearly a big chunk of legislation missing: the area of conflict resolution of local laws and the Internet. I don't think this WG can make legislation (who are we to do so?), give advice to governments and working directly with governments is the best approach. Would you be working with the GAC on this issue? Nathalie On Thursday, March 23, 2017 1:02 PM, John Bambenek <jcb@bambenekconsulting.com> wrote: Take on is a strong way of putting it. Public policy is about balancing of interests. DP authorities know that. So I intend to use my expertise to show them the best way to solve the problem. I don't expect the entire WG to fall in line. I intend to work with governments directly on that. Sent from my iPhone On Mar 23, 2017, at 11:47, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: I must say I am overwhelmed by the scope of this task. Can this WG really take on governments and challenge their practices? If so, I think I'll need a drink first. (Not really). Nathalie On Thursday, March 23, 2017 12:21 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: Hi, On Thu, Mar 23, 2017 at 09:08:59AM -0400, allison nixon wrote:
The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work.
I would encourage you to read Scott's messages on this a little more carefully, because I don't think that he's claiming he is covering those costs. What he is doing is demonstrating that the technology for different groups of people to be authenticated by various providers is available, already widely deployed in other parts of the Internet, and applicable to this case. That technology was heretofore unavailable for RDS the way it was for other things, because the historic RDS relies on the ancient whois protocol -- a protocol designed for a world where it was literally possible to get a list, on paper, of every single person who was connected to the Internet. (Some people in this effort have reported to me that they still have old copies lying around.) If your argument is instead, "But we don't have to pay the overhead of authentiction and authorization today, so it should remain that way forever," then I think you are going to have to do a better job arguing for that position. Because to me it is plainly absurd. The world has changed partly because the Internet has changed a great deal. Indeed, the very fact that the Internet can be instrumental in fraud in ways that it certainly could not have been instrumental in 1982 (when RFC 812 was published) suggests to me that appropriate authorization and authentication protocols around the RDS ought to have been embraced -- by law enforcement and others -- quite a long time ago. We ought to be ashamed it has taken us this long, when even Google is concerned about leaking this kind of data.
Also how will the need for historical whois be fulfilled?
This is in part an excellent question because it is not plain that all "historical whois" services are actually ok under existing policy. But of course, this WG is in a position to specify retention periods about data as part of the collection policies that we were working on. RDAP could easily work to provide a picture of something at some time in the past, assuming that the data is available. Whether the data ought to be is a different question, and one we should discuss rather than assume. There is a cost to be paid for collecting, keeping, and ensuring appropriate authorization in the disclosure of data. The existing practices externalize some of those costs onto the individuals whose data is being collected. I recognize that it might not be convenient to have those costs borne by the people who want access, but one of the things markets are good at is allocating resources according to how much value something brings. Perhaps if people had to endure the costs of their desire for access to the data, they would do a better job evaluating the balance of costs versus benefits.
Also, this gated access reminds me of how we treat personal data in the United States.
Speaking as a reluctant citizen of the US, I am sorry to say that US personal data protection is no sort of standard worth emulating. I believe it is only a matter of time before the legal system catches up with the frankly negligent handling of personal data in the US, and that the costs of insurance and liability will get to the point where corporations will get better at it. Even the USG has had major breaches of its databases. In my opinion, those breaches were made easier because the USG it collects too much, saves too much, and handles that collected stuff in a way that is too convenient to those who like to have all the data hanging around in the service of the security state. Peter Wayner's _Translucent Databases_ provides an excellent discussion of the general issues, and is not too long; it came out in 2002 and was hardly at the cutting edge of these discussions even then. I am not sure why the ICANN community has taken 15 years to get with the program, but I think this WG needs to find a way to do so. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I am setting up an INGO for the purpose. I am happy to work with whomever but considering the hostility for registrars I am not sure the GAC will be viable for me. I am friends with many congressmen and several DP authorities in the US are former students of mine so I already have access in the US. I will need to do footwork for other countries but that shouldn't be a heavy lift. Sent from my iPhone
On Mar 23, 2017, at 12:11, nathalie coupet <nathaliecoupet@yahoo.com> wrote:
Hi John,
I also think this is the way to go. There is clearly a big chunk of legislation missing: the area of conflict resolution of local laws and the Internet. I don't think this WG can make legislation (who are we to do so?), give advice to governments and working directly with governments is the best approach. Would you be working with the GAC on this issue?
Nathalie
On Thursday, March 23, 2017 1:02 PM, John Bambenek <jcb@bambenekconsulting.com> wrote:
Take on is a strong way of putting it. Public policy is about balancing of interests. DP authorities know that. So I intend to use my expertise to show them the best way to solve the problem.
I don't expect the entire WG to fall in line. I intend to work with governments directly on that.
Sent from my iPhone
On Mar 23, 2017, at 11:47, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
I must say I am overwhelmed by the scope of this task. Can this WG really take on governments and challenge their practices? If so, I think I'll need a drink first. (Not really).
Nathalie
On Thursday, March 23, 2017 12:21 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Thu, Mar 23, 2017 at 09:08:59AM -0400, allison nixon wrote:
The problems have nothing to do with your code, unless your code somehow simulates the cost of bureaucratic overhead of a bunch of already-overworked FBI agents "certifying" tens of thousands of people across the country who just want to get back to work.
I would encourage you to read Scott's messages on this a little more carefully, because I don't think that he's claiming he is covering those costs. What he is doing is demonstrating that the technology for different groups of people to be authenticated by various providers is available, already widely deployed in other parts of the Internet, and applicable to this case. That technology was heretofore unavailable for RDS the way it was for other things, because the historic RDS relies on the ancient whois protocol -- a protocol designed for a world where it was literally possible to get a list, on paper, of every single person who was connected to the Internet. (Some people in this effort have reported to me that they still have old copies lying around.)
If your argument is instead, "But we don't have to pay the overhead of authentiction and authorization today, so it should remain that way forever," then I think you are going to have to do a better job arguing for that position. Because to me it is plainly absurd. The world has changed partly because the Internet has changed a great deal. Indeed, the very fact that the Internet can be instrumental in fraud in ways that it certainly could not have been instrumental in 1982 (when RFC 812 was published) suggests to me that appropriate authorization and authentication protocols around the RDS ought to have been embraced -- by law enforcement and others -- quite a long time ago. We ought to be ashamed it has taken us this long, when even Google is concerned about leaking this kind of data.
Also how will the need for historical whois be fulfilled?
This is in part an excellent question because it is not plain that all "historical whois" services are actually ok under existing policy. But of course, this WG is in a position to specify retention periods about data as part of the collection policies that we were working on. RDAP could easily work to provide a picture of something at some time in the past, assuming that the data is available. Whether the data ought to be is a different question, and one we should discuss rather than assume. There is a cost to be paid for collecting, keeping, and ensuring appropriate authorization in the disclosure of data. The existing practices externalize some of those costs onto the individuals whose data is being collected. I recognize that it might not be convenient to have those costs borne by the people who want access, but one of the things markets are good at is allocating resources according to how much value something brings. Perhaps if people had to endure the costs of their desire for access to the data, they would do a better job evaluating the balance of costs versus benefits.
Also, this gated access reminds me of how we treat personal data in the United States.
Speaking as a reluctant citizen of the US, I am sorry to say that US personal data protection is no sort of standard worth emulating. I believe it is only a matter of time before the legal system catches up with the frankly negligent handling of personal data in the US, and that the costs of insurance and liability will get to the point where corporations will get better at it.
Even the USG has had major breaches of its databases. In my opinion, those breaches were made easier because the USG it collects too much, saves too much, and handles that collected stuff in a way that is too convenient to those who like to have all the data hanging around in the service of the security state. Peter Wayner's _Translucent Databases_ provides an excellent discussion of the general issues, and is not too long; it came out in 2002 and was hardly at the cutting edge of these discussions even then. I am not sure why the ICANN community has taken 15 years to get with the program, but I think this WG needs to find a way to do so.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
nathalie coupet via gnso-rds-pdp-wg wrote:
I must say I am overwhelmed by the scope of this task. Can this WG really take on governments and challenge their practices? If so, I think I'll need a drink first. (Not really). Nathalie
Agreed, ICANN can't fix governments, nor should it try. -- Denny Watson Sr. Investigator The Spamhaus Project
Correct, ICANN and our group just needs to ensure its policies remain compliant with applicable government practices, laws and regulations. Am 27.03.2017 um 15:22 schrieb Denny Watson:
nathalie coupet via gnso-rds-pdp-wg wrote:
I must say I am overwhelmed by the scope of this task. Can this WG really take on governments and challenge their practices? If so, I think I'll need a drink first. (Not really). Nathalie
Agreed, ICANN can't fix governments, nor should it try.
-- 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.
Respectfully I disagree. We are the domain experts here. Of course we should talk to regulators to better inform them of how the system works, why it needs to work that way and the best way they can balance their policy goals against other interests. Now whether this *group* does that is another question. But I certainly didn't give up my rights as a citizen to influence government because I volunteered for an ICANN workgroup. Sent from my iPhone
On Mar 27, 2017, at 09:08, Volker Greimann <vgreimann@key-systems.net> wrote:
Correct, ICANN and our group just needs to ensure its policies remain compliant with applicable government practices, laws and regulations.
Am 27.03.2017 um 15:22 schrieb Denny Watson: nathalie coupet via gnso-rds-pdp-wg wrote:
I must say I am overwhelmed by the scope of this task. Can this WG really take on governments and challenge their practices? If so, I think I'll need a drink first. (Not really). Nathalie
Agreed, ICANN can't fix governments, nor should it try.
-- 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 Mon, Mar 27, 2017 at 12:57:12PM -0500, John Bambenek via gnso-rds-pdp-wg wrote:
Respectfully I disagree. We are the domain experts here. Of course we should talk to regulators to better inform them of how the system works, why it needs to work that way and the best way they can balance their policy goals against other interests.
I would like to know, in the above passage, what "the system", "works", "needs to work that way" all mean. I thought that part of what this WG was supposed to be doing was determining those things. If the above is instead an assumption that the existing whois deployed the way it is "works", then I believe the argument is begging the question. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Thanks, Volker, Currently, China is drafting privacy regulations, and it looks like personal data, crossing borders might be near impossible when this is finished and becomes law. The USA turning 180 degrees shows fast this landscape is evolving, next election (or faster) we might see another 180 degrees again. Volker is right; we need to make sure our policies remain compliant with applicable government practices, laws & regulations. That is the way forward, it is not easy, but for sure this WG can do it. Thanks, Theo On 27-3-2017 16:08, Volker Greimann wrote:
Correct, ICANN and our group just needs to ensure its policies remain compliant with applicable government practices, laws and regulations.
Am 27.03.2017 um 15:22 schrieb Denny Watson:
nathalie coupet via gnso-rds-pdp-wg wrote:
I must say I am overwhelmed by the scope of this task. Can this WG really take on governments and challenge their practices? If so, I think I'll need a drink first. (Not really). Nathalie
Agreed, ICANN can't fix governments, nor should it try.
-- 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
I think we all want changes -- at least in modernizing the system and getting the data on a better technical platform. Unfortunately, that's wrapped up in (or held hostage by) a whole raft of other concerns. As for fears (aside from clowns): 1. *Losing access*. For purposes of this response, it's not necessary to provide an exhaustive list of uses for Whois/RDS records, but to highlight a few from the point of view of an attorney in private practice: Whois records are a standard and necessary tool in conducting transactional due diligence (both buy-side and sell-side), IP audits and trademark "clearance". Also, Whois records are a standard and necessary tool in investigating phishers, spearphishers, fraudsters, scammers, infringers, counterfeiters, data thieves, etc., etc. 2. *Not finding solutions in this WG*. As a lawyer, I recognize the necessity of navigating the legal landscape and mitigating legal risk. Those who collect, hold and provide access to Whois/RDS data need to be able to comply with applicable laws and not be made into targets for enforcement of those laws. But "navigating the legal landscape" can't be the equivalent of staying in bed because it's the best way to avoid car accidents. Rather, the essence of navigating the legal landscape is finding a way to accomplish objectives to the greatest possible extent within the bounds of the law. From the IP stakeholder point of view, that means, among other things, maintaining (and potentially improving) access, and improving accuracy and contactability. My fear is that we will not learn how to do this -- how to accomplish these objectives to the greatest extent within the bounds of the law. I'm not enough of a worldwide data protection and privacy law savant to know how to do this myself. I hope that those who do know more will help. Unfortunately, some (many?) who do know more seem only to be interested in building higher, thicker and more impregnable walls around data, rather than providing solutions to allow access. Frankly, I found the data protection commissioners at ICANN58 to be in this mold -- more data privacy "guardians" than objective experts. (I'm waiting for the data access commissioners to show up, to provide some counterpoint. Since these don't exist, we'll need to get that counterpoint elsewhere.) As long as we stay dug in to our trenches, we're just squandering the opportunities that this WG offers. (Rather than "trenches," I prefer the analogy of a high school dance, where everyone is stuck to the wall, and no one is asking anyone to dance. The trench analogy does not end nearly as well.) Greg Shatan P.S. Clowns exist only to make you smile. Why so scary? *Greg Shatan *C: 917-816-6428 S: gsshatan Phone-to-Skype: 646-845-9428 gregshatanipc@gmail.com On Wed, Mar 22, 2017 at 12:33 PM, John Horton <john.horton@legitscript.com> wrote:
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*Follow LegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | *Blog <http://blog.legitscript.com>* | Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I would hope that all of us can agree on this assuming that we can agree as a WG on the objective: “the essence of navigating the legal landscape is finding a way to accomplish objectives to the greatest possible extent within the bounds of the law”. I am not opposed to members starting in their respective trenches but we now need to start looking for ways to get out of our trenches. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Shatan Sent: Wednesday, March 22, 2017 1:25 PM To: John Horton <john.horton@legitscript.com> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" I think we all want changes -- at least in modernizing the system and getting the data on a better technical platform. Unfortunately, that's wrapped up in (or held hostage by) a whole raft of other concerns. As for fears (aside from clowns): 1. Losing access. For purposes of this response, it's not necessary to provide an exhaustive list of uses for Whois/RDS records, but to highlight a few from the point of view of an attorney in private practice: Whois records are a standard and necessary tool in conducting transactional due diligence (both buy-side and sell-side), IP audits and trademark "clearance". Also, Whois records are a standard and necessary tool in investigating phishers, spearphishers, fraudsters, scammers, infringers, counterfeiters, data thieves, etc., etc. 2. Not finding solutions in this WG. As a lawyer, I recognize the necessity of navigating the legal landscape and mitigating legal risk. Those who collect, hold and provide access to Whois/RDS data need to be able to comply with applicable laws and not be made into targets for enforcement of those laws. But "navigating the legal landscape" can't be the equivalent of staying in bed because it's the best way to avoid car accidents. Rather, the essence of navigating the legal landscape is finding a way to accomplish objectives to the greatest possible extent within the bounds of the law. From the IP stakeholder point of view, that means, among other things, maintaining (and potentially improving) access, and improving accuracy and contactability. My fear is that we will not learn how to do this -- how to accomplish these objectives to the greatest extent within the bounds of the law. I'm not enough of a worldwide data protection and privacy law savant to know how to do this myself. I hope that those who do know more will help. Unfortunately, some (many?) who do know more seem only to be interested in building higher, thicker and more impregnable walls around data, rather than providing solutions to allow access. Frankly, I found the data protection commissioners at ICANN58 to be in this mold -- more data privacy "guardians" than objective experts. (I'm waiting for the data access commissioners to show up, to provide some counterpoint. Since these don't exist, we'll need to get that counterpoint elsewhere.) As long as we stay dug in to our trenches, we're just squandering the opportunities that this WG offers. (Rather than "trenches," I prefer the analogy of a high school dance, where everyone is stuck to the wall, and no one is asking anyone to dance. The trench analogy does not end nearly as well.) Greg Shatan P.S. Clowns exist only to make you smile. Why so scary? Greg Shatan C: 917-816-6428 S: gsshatan Phone-to-Skype: 646-845-9428 gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> On Wed, Mar 22, 2017 at 12:33 PM, John Horton <john.horton@legitscript.com<mailto:john.horton@legitscript.com>> wrote: Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript <https://docs.google.com/uc?export=download&id=0B13GfLt8zwZJRXE5UTAtclVxdTg&r...> Follow LegitScript: LinkedIn<http://www.linkedin.com/company/legitscript-com> | Facebook<https://www.facebook.com/LegitScript> | Twitter<https://twitter.com/legitscript> | Blog<http://blog.legitscript.com> | Google+<https://plus.google.com/112436813474708014933/posts> <https://www.legitscript.com/wp-content/uploads/2015/09/LegitScript-Workplace...> <https://docs.google.com/uc?export=download&id=0B13GfLt8zwZJTmNWbmcwOTVJMXc&r...> On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone > On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote: > >> On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: >> Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. >> > > I thought the WG had already decided on a different (multi-pass) > strategy, in which data collection itself was treated first with the > principle that, if there were some (legitmate, hand-wave hand-wave) > purpose then collection would be considered. Later, the further > question of access to such collected items would be taken up. > > I don't really care which way we do this, but it seems to me that we > need to stop arguing about the way by which we'll reach a result and > start actually doing work in the direction of some result. The > meta-discussions about process are wearing out contributors (well, at > least one contributor!) and creating the condition in which those who > want no changes at all will get their way by exhaustion. If ICANN is > incapable of coming to terms with the deficiencies of whois (the > protocol) after all this time, it will be revealed to be ridiculous. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> > _______________________________________________ > 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
I know that we have been focusing on the Data Protection issues lately but please be assured that we will deliberate needs that at present may seem to conflict of Data Protection requirements and try to find solutions where both needs can be legally addressed. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of John Horton Sent: Wednesday, March 22, 2017 12:33 PM To: nathalie coupet <nathaliecoupet@yahoo.com> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript <https://docs.google.com/uc?export=download&id=0B13GfLt8zwZJRXE5UTAtclVxdTg&r...> Follow LegitScript: LinkedIn<http://www.linkedin.com/company/legitscript-com> | Facebook<https://www.facebook.com/LegitScript> | Twitter<https://twitter.com/legitscript> | Blog<http://blog.legitscript.com> | Google+<https://plus.google.com/112436813474708014933/posts> <https://www.legitscript.com/wp-content/uploads/2015/09/LegitScript-Workplace...> <https://docs.google.com/uc?export=download&id=0B13GfLt8zwZJTmNWbmcwOTVJMXc&r...> On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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 all, I hope everyone got home safe that attended ICANN58 :) Having just sat through and played catch up on this thread, a few things stand out to me. On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown) The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations. Some points/thoughts : * Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) * The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. * Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. * Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). * I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome. Kind regards, Chris From: "John Horton" <john.horton@legitscript.com> To: "nathalie coupet" <nathaliecoupet@yahoo.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript Follow Legit Script : LinkedIn | Facebook | Twitter | Blog | Google+ On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org > wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan < ajs@anvilwalrusden.com > wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Typo materialistic should have been minimalistic Kind regards, Chris From: "Chris Pelling" <chris@netearth.net> To: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 23 March, 2017 12:06:01 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi all, I hope everyone got home safe that attended ICANN58 :) Having just sat through and played catch up on this thread, a few things stand out to me. On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown) The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations. Some points/thoughts : * Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) * The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. * Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. * Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). * I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome. Kind regards, Chris From: "John Horton" <john.horton@legitscript.com> To: "nathalie coupet" <nathaliecoupet@yahoo.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript Follow Legit Script : LinkedIn | Facebook | Twitter | Blog | Google+ On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org > wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan < ajs@anvilwalrusden.com > wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ 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
Registrars are not charging their customers extra for use of their privacy rights, they are charging extra for a value added service: - provision of alternate address data - assumption of legal risks involved in being listed as registered name holder for a third party domain - forwarding of email - staffing of abuse team to handle and review any incoming communications - compliance with all requirements of whois privacy spec of the RAA.
Several registrars already offer free whois privacy. They made it work, so you should keep up! Maybe dumb bad actors. Savvy bad actors just populate whois with data of
unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings. Some points/thoughts :
Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government. On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote:
Typo materialistic should have been minimalistic
Kind regards,
Chris
------------------------------ *From: *"Chris Pelling" <chris@netearth.net> *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 23 March, 2017 12:06:01
*Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts :
- Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) - The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. - Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. - Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). - I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
------------------------------ *From: *"John Horton" <john.horton@legitscript.com> *To: *"nathalie coupet" <nathaliecoupet@yahoo.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Wednesday, 22 March, 2017 16:33:22 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*Follow LegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | Blog <http://blog.legitscript.com> | Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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
-- _________________________________ Note to self: Pillage BEFORE burning.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
Is the new contacts created after the 2013 agreement was in production? Remember contacts in use before that date are not part of the validation before there are made a change of info, so you shooting at not good enough validation might be a little out of range -- 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
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or... Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free". TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net <mailto:chris@netearth.net>> wrote:
Typo materialistic should have been minimalistic
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Chris Pelling" <chris@netearth.net <mailto:chris@netearth.net>> *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Thursday, 23 March, 2017 12:06:01
*Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts :
* Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) * The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. * Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. * Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). * I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"John Horton" <john.horton@legitscript.com <mailto:john.horton@legitscript.com>> *To: *"nathalie coupet" <nathaliecoupet@yahoo.com <mailto:nathaliecoupet@yahoo.com>> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Wednesday, 22 March, 2017 16:33:22 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*FollowLegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | Blog <http://blog.legitscript.com> |Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
> On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote: > >> On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: >> Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. >> > > I thought the WG had already decided on a different (multi-pass) > strategy, in which data collection itself was treated first with the > principle that, if there were some (legitmate, hand-wave hand-wave) > purpose then collection would be considered. Later, the further > question of access to such collected items would be taken up. > > I don't really care which way we do this, but it seems to me that we > need to stop arguing about the way by which we'll reach a result and > start actually doing work in the direction of some result. The > meta-discussions about process are wearing out contributors (well, at > least one contributor!) and creating the condition in which those who > want no changes at all will get their way by exhaustion. If ICANN is > incapable of coming to terms with the deficiencies of whois (the > protocol) after all this time, it will be revealed to be ridiculous. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> > _______________________________________________ > 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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.
Soon all of you will be forced to offer whois privacy for free. I'll leave it to you to figure out the economics. Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote: Typo materialistic should have been minimalistic
Kind regards,
Chris
From: "Chris Pelling" <chris@netearth.net> To: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 23 March, 2017 12:06:01
Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
From: "John Horton" <john.horton@legitscript.com> To: "nathalie coupet" <nathaliecoupet@yahoo.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
Follow LegitScript: LinkedIn | Facebook | Twitter | Blog | Google+
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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 Robert Heinlein already correctly wrote half a century ago: "There ain't no such thing as a free lunch" Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another. So why not rather find a legally compliant solution that would fit the requirements? Volker Am 23.03.2017 um 15:11 schrieb John Bambenek:
Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net <mailto:chris@netearth.net>> wrote:
Typo materialistic should have been minimalistic
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Chris Pelling" <chris@netearth.net <mailto:chris@netearth.net>> *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Thursday, 23 March, 2017 12:06:01
*Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts :
* Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) * The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. * Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. * Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). * I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"John Horton" <john.horton@legitscript.com <mailto:john.horton@legitscript.com>> *To: *"nathalie coupet" <nathaliecoupet@yahoo.com <mailto:nathaliecoupet@yahoo.com>> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Wednesday, 22 March, 2017 16:33:22 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*FollowLegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | Blog <http://blog.legitscript.com> |Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
> On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote: > >> On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: >> Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. >> > > I thought the WG had already decided on a different (multi-pass) > strategy, in which data collection itself was treated first with the > principle that, if there were some (legitmate, hand-wave hand-wave) > purpose then collection would be considered. Later, the further > question of access to such collected items would be taken up. > > I don't really care which way we do this, but it seems to me that we > need to stop arguing about the way by which we'll reach a result and > start actually doing work in the direction of some result. The > meta-discussions about process are wearing out contributors (well, at > least one contributor!) and creating the condition in which those who > want no changes at all will get their way by exhaustion. If ICANN is > incapable of coming to terms with the deficiencies of whois (the > protocol) after all this time, it will be revealed to be ridiculous. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> > _______________________________________________ > 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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 <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.
Yes someone will have to pay for it. You will. And I'll be the one that makes that happen. Deal with it. Sent from my iPhone
On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net> wrote:
As Robert Heinlein already correctly wrote half a century ago:
"There ain't no such thing as a free lunch"
Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another. So why not rather find a legally compliant solution that would fit the requirements?
Volker
Am 23.03.2017 um 15:11 schrieb John Bambenek: Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote: Typo materialistic should have been minimalistic
Kind regards,
Chris
From: "Chris Pelling" <chris@netearth.net> To: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 23 March, 2017 12:06:01
Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
From: "John Horton" <john.horton@legitscript.com> To: "nathalie coupet" <nathaliecoupet@yahoo.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
Follow LegitScript: LinkedIn | Facebook | Twitter | Blog | Google+
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
> On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: > >> On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: >> Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. >> > > I thought the WG had already decided on a different (multi-pass) > strategy, in which data collection itself was treated first with the > principle that, if there were some (legitmate, hand-wave hand-wave) > purpose then collection would be considered. Later, the further > question of access to such collected items would be taken up. > > I don't really care which way we do this, but it seems to me that we > need to stop arguing about the way by which we'll reach a result and > start actually doing work in the direction of some result. The > meta-discussions about process are wearing out contributors (well, at > least one contributor!) and creating the condition in which those who > want no changes at all will get their way by exhaustion. If ICANN is > incapable of coming to terms with the deficiencies of whois (the > protocol) after all this time, it will be revealed to be ridiculous. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
(Off-list) Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me. - Ayden On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: Yes someone will have to pay for it. You will. And I'll be the one that makes that happen. Deal with it. Sent from my iPhone On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net> wrote: As Robert Heinlein already correctly wrote half a century ago: "There ain't no such thing as a free lunch" Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another. So why not rather find a legally compliant solution that would fit the requirements? Volker Am 23.03.2017 um 15:11 schrieb John Bambenek: Soon all of you will be forced to offer whois privacy for free. I'll leave it to you to figure out the economics. Sent from my iPhone On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote: Hi Allison, Several registrars already offer free whois privacy. They made it work, so you should keep up! Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or... Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free". TANSTAAFL. Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well. I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings. I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it. Some points/thoughts :Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?)The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant.Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions.Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it).I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government. Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to. On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote: Typo materialistic should have been minimalistic Kind regards, Chris --------------------------------------------------------------- From: "Chris Pelling" <chris@netearth.net> To: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 23 March, 2017 12:06:01 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi all, I hope everyone got home safe that attended ICANN58 :) Having just sat through and played catch up on this thread, a few things stand out to me. On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown) The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations. Some points/thoughts : - Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) - The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. - Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. - Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). - I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome. Kind regards, Chris --------------------------------------------------------------- From: "John Horton" <john.horton@legitscript.com> To: "nathalie coupet" <nathaliecoupet@yahoo.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript Follow LegitScript: [LinkedIn](http://www.linkedin.com/company/legitscript-com) | [Facebook](https://www.facebook.com/LegitScript) | [Twitter](https://twitter.com/legitscript) | [Blog](http://blog.legitscript.com) | [Google+](https://plus.google.com/112436813474708014933/posts) On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg ______________________________ _________________ 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 -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Clearly the below comment wasn't intended for the entire list. Please ignore. Thank you. - Ayden On Thu, Mar 23, 2017 at 2:29 pm, Ayden Férdeline <icann@ferdeline.com> wrote: (Off-list) Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me. - Ayden On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: Yes someone will have to pay for it. You will. And I'll be the one that makes that happen. Deal with it. Sent from my iPhone On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net> wrote: As Robert Heinlein already correctly wrote half a century ago: "There ain't no such thing as a free lunch" Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another. So why not rather find a legally compliant solution that would fit the requirements? Volker Am 23.03.2017 um 15:11 schrieb John Bambenek: Soon all of you will be forced to offer whois privacy for free. I'll leave it to you to figure out the economics. Sent from my iPhone On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote: Hi Allison, Several registrars already offer free whois privacy. They made it work, so you should keep up! Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or... Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free". TANSTAAFL. Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well. I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings. I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it. Some points/thoughts :Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?)The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant.Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions.Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it).I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government. Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to. On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote: Typo materialistic should have been minimalistic Kind regards, Chris --------------------------------------------------------------- From: "Chris Pelling" <chris@netearth.net> To: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 23 March, 2017 12:06:01 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi all, I hope everyone got home safe that attended ICANN58 :) Having just sat through and played catch up on this thread, a few things stand out to me. On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown) The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations. Some points/thoughts : - Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) - The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. - Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. - Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). - I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome. Kind regards, Chris --------------------------------------------------------------- From: "John Horton" <john.horton@legitscript.com> To: "nathalie coupet" <nathaliecoupet@yahoo.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript Follow LegitScript: [LinkedIn](http://www.linkedin.com/company/legitscript-com) | [Facebook](https://www.facebook.com/LegitScript) | [Twitter](https://twitter.com/legitscript) | [Blog](http://blog.legitscript.com) | [Google+](https://plus.google.com/112436813474708014933/posts) On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg ______________________________ _________________ 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 -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Hi. Does the lack of substance include the notion of whois privacy for free and putting true consent into the mix as impacting privacy considerations figure into that? Sent from my iPhone
On Mar 23, 2017, at 09:29, Ayden Férdeline <icann@ferdeline.com> wrote:
(Off-list)
Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me.
- Ayden
On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: Yes someone will have to pay for it.
You will. And I'll be the one that makes that happen.
Deal with it.
Sent from my iPhone
On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net> wrote:
As Robert Heinlein already correctly wrote half a century ago:
"There ain't no such thing as a free lunch"
Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another. So why not rather find a legally compliant solution that would fit the requirements?
Volker
Am 23.03.2017 um 15:11 schrieb John Bambenek: Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
> Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
> Some points/thoughts : > Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) > The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. > Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. > Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). > I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
> On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote: > Typo materialistic should have been minimalistic > > Kind regards, > > Chris > > From: "Chris Pelling" <chris@netearth.net> > To: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> > Sent: Thursday, 23 March, 2017 12:06:01 > > Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" > > Hi all, > > I hope everyone got home safe that attended ICANN58 :) > > Having just sat through and played catch up on this thread, a few things stand out to me. > > On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown) > > The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations. > > Some points/thoughts : > Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) > The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. > Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. > Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). > I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) > As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome. > > Kind regards, > > Chris > > From: "John Horton" <john.horton@legitscript.com> > To: "nathalie coupet" <nathaliecoupet@yahoo.com> > Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> > Sent: Wednesday, 22 March, 2017 16:33:22 > Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" > > Thanks, Nathalie. I'm sure many share your frustration! > > I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. > > Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. > > John Horton > President and CEO, LegitScript > > > Follow LegitScript: LinkedIn | Facebook | Twitter | Blog | Google+ > > > >> On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: >> +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. >> If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. >> Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? >> Or maybe, in last resort, we should just vote for the best proposal and go home? >> >> Nathalie >> >> >> Sent from my iPhone >> >> > On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: >> > >> >> On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: >> >> Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. >> >> >> > >> > I thought the WG had already decided on a different (multi-pass) >> > strategy, in which data collection itself was treated first with the >> > principle that, if there were some (legitmate, hand-wave hand-wave) >> > purpose then collection would be considered. Later, the further >> > question of access to such collected items would be taken up. >> > >> > I don't really care which way we do this, but it seems to me that we >> > need to stop arguing about the way by which we'll reach a result and >> > start actually doing work in the direction of some result. The >> > meta-discussions about process are wearing out contributors (well, at >> > least one contributor!) and creating the condition in which those who >> > want no changes at all will get their way by exhaustion. If ICANN is >> > incapable of coming to terms with the deficiencies of whois (the >> > protocol) after all this time, it will be revealed to be ridiculous. >> > >> > Best regards, >> > >> > A >> > >> > -- >> > Andrew Sullivan >> > ajs@anvilwalrusden.com >> > ______________________________ _________________ >> > gnso-rds-pdp-wg mailing list >> > gnso-rds-pdp-wg@icann.org >> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >> >> ______________________________ _________________ >> gnso-rds-pdp-wg mailing list >> gnso-rds-pdp-wg@icann.org >> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg > > > ______________________________ _________________ > 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
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
The simultaneous moaning over a small whois privacy fee, with the total disregard and ignorance over current whois use cases, and the desire to destroy a company over it(oops, I mean "step on toes"), and impose various other burdens that must be borne by "someone else", because the registrars can't possibly spend a dime... bother me quite a bit more. John's tone is more than justified considering the unreasonable attitudes prevalent here. If yall are going to claim that all current use cases are not only illegal but invalid, you won't get much sympathy over raising your fees a dollar to make them "legal" again. On Thu, Mar 23, 2017 at 10:29 AM, Ayden Férdeline <icann@ferdeline.com> wrote:
(Off-list)
Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me.
- Ayden
On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
Yes someone will have to pay for it.
You will. And I'll be the one that makes that happen.
Deal with it.
Sent from my iPhone
On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net> wrote:
As Robert Heinlein already correctly wrote half a century ago:
"There ain't no such thing as a free lunch"
Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another.
So why not rather find a legally compliant solution that would fit the requirements?
Volker
Am 23.03.2017 um 15:11 schrieb John Bambenek:
Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of
unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts :
Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote:
Typo materialistic should have been minimalistic
Kind regards,
Chris
------------------------------ *From: *"Chris Pelling" <chris@netearth.net> *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 23 March, 2017 12:06:01
*Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts :
- Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) - The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. - Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. - Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). - I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
------------------------------ *From: *"John Horton" <john.horton@legitscript.com> *To: *"nathalie coupet" <nathaliecoupet@yahoo.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Wednesday, 22 March, 2017 16:33:22 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*Follow LegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | Blog <http://blog.legitscript.com> | Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ 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
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
Imagine the moaning if we did what he proposed? Registrars activating whois privacy for everyone would all but eliminate the ability of foreign law enforcement and those in the business of fighting cybercrime as a non-authorized entity. Whois as it is today would cease to exist from one day to the next. I somehow feel that this is not what you really want. So let's try to find a solution that would maintain the essential usability of whois and at the same time remains within the confines of legal requirements. If that is an unreasonable suggestion, you can call me unreasonable. Am 23.03.2017 um 15:55 schrieb allison nixon:
The simultaneous moaning over a small whois privacy fee, with the total disregard and ignorance over current whois use cases, and the desire to destroy a company over it(oops, I mean "step on toes"), and impose various other burdens that must be borne by "someone else", because the registrars can't possibly spend a dime... bother me quite a bit more. John's tone is more than justified considering the unreasonable attitudes prevalent here.
If yall are going to claim that all current use cases are not only illegal but invalid, you won't get much sympathy over raising your fees a dollar to make them "legal" again.
On Thu, Mar 23, 2017 at 10:29 AM, Ayden Férdeline <icann@ferdeline.com <mailto:icann@ferdeline.com>> wrote:
(Off-list)
Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me.
- Ayden
On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
Yes someone will have to pay for it.
You will. And I'll be the one that makes that happen.
Deal with it.
Sent from my iPhone
On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
As Robert Heinlein already correctly wrote half a century ago:
"There ain't no such thing as a free lunch"
Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another.
So why not rather find a legally compliant solution that would fit the requirements?
Volker
Am 23.03.2017 um 15:11 schrieb John Bambenek:
Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net <mailto:chris@netearth.net>> wrote:
Typo materialistic should have been minimalistic
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Chris Pelling" <chris@netearth.net <mailto:chris@netearth.net>> *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Thursday, 23 March, 2017 12:06:01
*Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts :
* Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) * The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. * Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. * Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). * I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"John Horton" <john.horton@legitscript.com <mailto:john.horton@legitscript.com>> *To: *"nathalie coupet" <nathaliecoupet@yahoo.com <mailto:nathaliecoupet@yahoo.com>> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Wednesday, 22 March, 2017 16:33:22 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*FollowLegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | Blog <http://blog.legitscript.com> | Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
> On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote: > >> On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: >> Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. >> > > I thought the WG had already decided on a different (multi-pass) > strategy, in which data collection itself was treated first with the > principle that, if there were some (legitmate, hand-wave hand-wave) > purpose then collection would be considered. Later, the further > question of access to such collected items would be taken up. > > I don't really care which way we do this, but it seems to me that we > need to stop arguing about the way by which we'll reach a result and > start actually doing work in the direction of some result. The > meta-discussions about process are wearing out contributors (well, at > least one contributor!) and creating the condition in which those who > want no changes at all will get their way by exhaustion. If ICANN is > incapable of coming to terms with the deficiencies of whois (the > protocol) after all this time, it will be revealed to be ridiculous. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> > ______________________________ _________________ > 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>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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.
So we make it opt-in. The most abused registrars almost all give free whois privacy (somehow, magically), for at least the first year, and malware domains dont usually last a year, so it changes nothing.
No deal. Sorry, but you do not get to claim to be the only source of expertise in your line of work.
I'm sure you already know this about malicious domains, as you are a renowned expert in cybersecurity and researching cybercrime. On Thu, Mar 23, 2017 at 11:20 AM, Volker Greimann <vgreimann@key-systems.net
wrote:
Imagine the moaning if we did what he proposed? Registrars activating whois privacy for everyone would all but eliminate the ability of foreign law enforcement and those in the business of fighting cybercrime as a non-authorized entity. Whois as it is today would cease to exist from one day to the next.
I somehow feel that this is not what you really want. So let's try to find a solution that would maintain the essential usability of whois and at the same time remains within the confines of legal requirements. If that is an unreasonable suggestion, you can call me unreasonable.
Am 23.03.2017 um 15:55 schrieb allison nixon:
The simultaneous moaning over a small whois privacy fee, with the total disregard and ignorance over current whois use cases, and the desire to destroy a company over it(oops, I mean "step on toes"), and impose various other burdens that must be borne by "someone else", because the registrars can't possibly spend a dime... bother me quite a bit more. John's tone is more than justified considering the unreasonable attitudes prevalent here.
If yall are going to claim that all current use cases are not only illegal but invalid, you won't get much sympathy over raising your fees a dollar to make them "legal" again.
On Thu, Mar 23, 2017 at 10:29 AM, Ayden Férdeline <icann@ferdeline.com> wrote:
(Off-list)
Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me.
- Ayden
On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
Yes someone will have to pay for it.
You will. And I'll be the one that makes that happen.
Deal with it.
Sent from my iPhone
On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net> wrote:
As Robert Heinlein already correctly wrote half a century ago:
"There ain't no such thing as a free lunch"
Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another.
So why not rather find a legally compliant solution that would fit the requirements?
Volker
Am 23.03.2017 um 15:11 schrieb John Bambenek:
Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of
unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts :
Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote:
Typo materialistic should have been minimalistic
Kind regards,
Chris
------------------------------ *From: *"Chris Pelling" <chris@netearth.net> *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 23 March, 2017 12:06:01
*Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts :
- Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) - The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. - Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. - Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). - I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
------------------------------ *From: *"John Horton" <john.horton@legitscript.com> *To: *"nathalie coupet" <nathaliecoupet@yahoo.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Wednesday, 22 March, 2017 16:33:22 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*Follow LegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | Blog <http://blog.legitscript.com> | Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ 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
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/l istinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/l istinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
Hi Allison, I do not know about other registrars, I just know what I see for myself. And from that, it is impossible to generalize the relationship of domain age and abuse. Some domains are aged remain dormant for months or even years before their first abusive use while others are abused from the second they are activated. If there were a way to prevent registrations for abusive use at the time of registration, most registrars I know would be very happy to know it. V. Am 23.03.2017 um 16:31 schrieb allison nixon:
So we make it opt-in. The most abused registrars almost all give free whois privacy (somehow, magically), for at least the first year, and malware domains dont usually last a year, so it changes nothing.
No deal. Sorry, but you do not get to claim to be the only source of expertise in your line of work.
I'm sure you already know this about malicious domains, as you are a renowned expert in cybersecurity and researching cybercrime.
On Thu, Mar 23, 2017 at 11:20 AM, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Imagine the moaning if we did what he proposed? Registrars activating whois privacy for everyone would all but eliminate the ability of foreign law enforcement and those in the business of fighting cybercrime as a non-authorized entity. Whois as it is today would cease to exist from one day to the next.
I somehow feel that this is not what you really want. So let's try to find a solution that would maintain the essential usability of whois and at the same time remains within the confines of legal requirements. If that is an unreasonable suggestion, you can call me unreasonable.
Am 23.03.2017 um 15:55 schrieb allison nixon:
The simultaneous moaning over a small whois privacy fee, with the total disregard and ignorance over current whois use cases, and the desire to destroy a company over it(oops, I mean "step on toes"), and impose various other burdens that must be borne by "someone else", because the registrars can't possibly spend a dime... bother me quite a bit more. John's tone is more than justified considering the unreasonable attitudes prevalent here.
If yall are going to claim that all current use cases are not only illegal but invalid, you won't get much sympathy over raising your fees a dollar to make them "legal" again.
On Thu, Mar 23, 2017 at 10:29 AM, Ayden Férdeline <icann@ferdeline.com <mailto:icann@ferdeline.com>> wrote:
(Off-list)
Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me.
- Ayden
On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> wrote:
Yes someone will have to pay for it.
You will. And I'll be the one that makes that happen.
Deal with it.
Sent from my iPhone
On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
As Robert Heinlein already correctly wrote half a century ago:
"There ain't no such thing as a free lunch"
Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another.
So why not rather find a legally compliant solution that would fit the requirements?
Volker
Am 23.03.2017 um 15:11 schrieb John Bambenek:
Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Allison,
> > Several registrars already offer free whois privacy. > They made it work, so you should keep up! Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL. > > Maybe dumb bad actors. Savvy bad actors just > populate whois with data of unknowing third parties, > thereby rendering any verification and validation > instruments useless and inconveniencing the affected > data subjects as well. > > > I'm glad you know so much about how bad actors abuse > whois. But from my own limited experiences- I don't see > that many input validation mechanisms on bad domains > because there are a lot of "555-5555" phone numbers out > there and other arbitrary strings. I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it. > > > Some points/thoughts : > Cost of providing the service (this includes cost of > the office, personnel to run it - unless you are > going to offer this free "John B" to all ICANN > registrars ?) > The underlying data may not even be allowed to be > provided to the whois privacy service, unless it is > in the local jurisdiction of the registrant. > Harvesting and storage of whois data to be > re-wrapped and sold is illegal and many registrars > state this on the terms and conditions. > Gated access has to be properly defined for each > gate/right of access, an example, a registrar would > normally only need access to external whois for the > purpose of transferring a domain name - they have no > other reason to need access to this data. > (registration, is totally different as it doesnt > need access to the "whois") As above, storage of > whois data is illegal unless it was for a lawful > purpose and the only one I can think of is > transfers. ICANN require registrars to keep this > info for upto 2 or 7 years (cant remember which). > This will step on some registrars toes as well as > John H's toes whi have a business model around the > supply of whois data for commercial gain (namely > charging for it). > I am sorry to say that none of what the WG will do > or complete will stop bad actors, they are smart, > they are not dumb (well some of them are:) ) > > > so who decided that these normal uses of whois are > suddenly illegal? I hereby declare my allegiance to the > dark side. Down with the government. Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
> > > > > > On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling > <chris@netearth.net <mailto:chris@netearth.net>> wrote: > > Typo materialistic should have been minimalistic > > Kind regards, > > Chris > > ------------------------------------------------------------------------ > *From: *"Chris Pelling" <chris@netearth.net > <mailto:chris@netearth.net>> > *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org > <mailto:gnso-rds-pdp-wg@icann.org>> > *Sent: *Thursday, 23 March, 2017 12:06:01 > > *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for > "purpose in detail" > > Hi all, > > I hope everyone got home safe that attended ICANN58 :) > > Having just sat through and played catch up on this > thread, a few things stand out to me. > > On one side you have a stakeholder person (maybe > group) advocating they will pushing for "free whois > protection" provided by registrar which simply won't > happen - for a number of reasons (see below), > whereas the fundamental issue is what will be > collected and who will be able to see it. Maybe > this could be worked on from a materialistic point > of view, really what does WHOIS/RDS need to show as > its most basic data, I remember a discussion some > months ago where Michele mentioned about simply > domain name, dates of registration, expiry and DNS > servers. (registrar name and abuse contact details > are a given to be shown) > > The storage of such data depending on "whom" the > registrant and/or other contacts are located, and > where it is being seen from (different jurisdiction > for example) will come out further down the line in > our deliberations. > > Some points/thoughts : > > * Cost of providing the service (this includes > cost of the office, personnel to run it - unless > you are going to offer this free "John B" to all > ICANN registrars ?) > * The underlying data may not even be allowed to > be provided to the whois privacy service, unless > it is in the local jurisdiction of the registrant. > * Harvesting and storage of whois data to be > re-wrapped and sold is illegal and many > registrars state this on the terms and conditions. > * Gated access has to be properly defined for each > gate/right of access, an example, a registrar > would normally only need access to external > whois for the purpose of transferring a domain > name - they have no other reason to need access > to this data. (registration, is totally > different as it doesnt need access to the > "whois") As above, storage of whois data is > illegal unless it was for a lawful purpose and > the only one I can think of is transfers. ICANN > require registrars to keep this info for upto 2 > or 7 years (cant remember which). This will > step on some registrars toes as well as John H's > toes whi have a business model around the supply > of whois data for commercial gain (namely > charging for it). > * I am sorry to say that none of what the WG will > do or complete will stop bad actors, they are > smart, they are not dumb (well some of them are:) ) > > As for John H and clowns, I would gladly offer my > services to help you get over that :) My > issue/phobia is the dark, sadly for me that is a > reality I won't be able to overcome. > > Kind regards, > > Chris > > ------------------------------------------------------------------------ > *From: *"John Horton" <john.horton@legitscript.com > <mailto:john.horton@legitscript.com>> > *To: *"nathalie coupet" <nathaliecoupet@yahoo.com > <mailto:nathaliecoupet@yahoo.com>> > *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org > <mailto:gnso-rds-pdp-wg@icann.org>> > *Sent: *Wednesday, 22 March, 2017 16:33:22 > *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for > "purpose in detail" > > Thanks, Nathalie. I'm sure many share your frustration! > > I think that's a constructive question, and I'll > jump in. My biggest fear is that in the monitoring > that companies like mine do for banks, payment > providers, e-commerce companies, etc. that helps > determine whether a merchant is who they say they > are, and whether they are engaged in other bad > activity (i.e., laundering money) will be unable to > obtain access to the Whois records we need in order > to preserve the integrity of the payments system, > protect payment providers from risk, and > derivatively protect consumers. In other words, my > fear is that we'll lose access to Whois records, > which we need for that purpose. > > Actually, to be honest, that's not true -- my > biggest fear (to answer your question directly) is > of clowns, and every time I travel, I ask the hotel > to please check for clowns in my closet before I > enter the room. But I assume you didn't really want > to know my biggest fear -- you just want to know my > biggest fear in relation to Whois policy, correct? > Two different things, but yeah -- if a clown jumped > out of my hotel closet, that would probably be the > realization of my biggest fear. That's probably > nothing that this working group can do much about, > though. > > John Horton > President and CEO, LegitScript > > > *FollowLegitScript*: LinkedIn > <http://www.linkedin.com/company/legitscript-com> | > Facebook <https://www.facebook.com/LegitScript> | > Twitter <https://twitter.com/legitscript> | Blog > <http://blog.legitscript.com> | Google+ > <https://plus.google.com/112436813474708014933/posts> > > > > > On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via > gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org > <mailto:gnso-rds-pdp-wg@icann.org>> wrote: > > +1 I must say I'm a bit disillusioned by the > entire process. This PDP should look like a > negotiating table, instead it is more like a War > of Trenches. > If stakeholders are not motivated to negotiate, > there is no sense of urgency and stakes for > change are so low, then I wonder what we are > doing here in the first place. > Could every stakeholder state what their biggest > fear is, and we could try to avoid their > realization? > Or maybe, in last resort, we should just vote > for the best proposal and go home? > > Nathalie > > > Sent from my iPhone > > > On Mar 22, 2017, at 12:06 PM, Andrew Sullivan > <ajs@anvilwalrusden.com > <mailto:ajs@anvilwalrusden.com>> wrote: > > > >> On Wed, Mar 22, 2017 at 10:19:56AM -0500, > John Bambenek wrote: > >> Yes there is a difference which is why I am > using both words. And that's why I am suggesting > we talking about optional and maskable fields > right up front as part of the requirements > discussion not some ancillary discussion that > happens later after all the decisions are > already made. > >> > > > > I thought the WG had already decided on a > different (multi-pass) > > strategy, in which data collection itself was > treated first with the > > principle that, if there were some (legitmate, > hand-wave hand-wave) > > purpose then collection would be considered. > Later, the further > > question of access to such collected items > would be taken up. > > > > I don't really care which way we do this, but > it seems to me that we > > need to stop arguing about the way by which > we'll reach a result and > > start actually doing work in the direction of > some result. The > > meta-discussions about process are wearing out > contributors (well, at > > least one contributor!) and creating the > condition in which those who > > want no changes at all will get their way by > exhaustion. If ICANN is > > incapable of coming to terms with the > deficiencies of whois (the > > protocol) after all this time, it will be > revealed to be ridiculous. > > > > Best regards, > > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > <mailto:ajs@anvilwalrusden.com> > > ______________________________ _________________ > > 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> > > > > > -- > _________________________________ > Note to self: Pillage BEFORE burning. > > > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg > <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg> -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.:+49 (0) 6894 - 9396 901 <tel:+49%206894%209396901> Fax.:+49 (0) 6894 - 9396 851 <tel:+49%206894%209396851> Email:vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>
Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-- _________________________________ Note to self: Pillage BEFORE burning. -- 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.
If you are describing spam, or any other malicious domain that must "look legit" to a corporate filter, those often won't use WHOIS privacy anyways. WHOIS privacy makes them look shady. we're coping just fine with whois privacy as it is. we can deal with this system and you can eat a dollar. On Thu, Mar 23, 2017 at 11:37 AM, Volker Greimann <vgreimann@key-systems.net
wrote:
Hi Allison,
I do not know about other registrars, I just know what I see for myself. And from that, it is impossible to generalize the relationship of domain age and abuse. Some domains are aged remain dormant for months or even years before their first abusive use while others are abused from the second they are activated.
If there were a way to prevent registrations for abusive use at the time of registration, most registrars I know would be very happy to know it.
V.
Am 23.03.2017 um 16:31 schrieb allison nixon:
So we make it opt-in. The most abused registrars almost all give free whois privacy (somehow, magically), for at least the first year, and malware domains dont usually last a year, so it changes nothing.
No deal. Sorry, but you do not get to claim to be the only source of expertise in your line of work.
I'm sure you already know this about malicious domains, as you are a renowned expert in cybersecurity and researching cybercrime.
On Thu, Mar 23, 2017 at 11:20 AM, Volker Greimann < vgreimann@key-systems.net> wrote:
Imagine the moaning if we did what he proposed? Registrars activating whois privacy for everyone would all but eliminate the ability of foreign law enforcement and those in the business of fighting cybercrime as a non-authorized entity. Whois as it is today would cease to exist from one day to the next.
I somehow feel that this is not what you really want. So let's try to find a solution that would maintain the essential usability of whois and at the same time remains within the confines of legal requirements. If that is an unreasonable suggestion, you can call me unreasonable.
Am 23.03.2017 um 15:55 schrieb allison nixon:
The simultaneous moaning over a small whois privacy fee, with the total disregard and ignorance over current whois use cases, and the desire to destroy a company over it(oops, I mean "step on toes"), and impose various other burdens that must be borne by "someone else", because the registrars can't possibly spend a dime... bother me quite a bit more. John's tone is more than justified considering the unreasonable attitudes prevalent here.
If yall are going to claim that all current use cases are not only illegal but invalid, you won't get much sympathy over raising your fees a dollar to make them "legal" again.
On Thu, Mar 23, 2017 at 10:29 AM, Ayden Férdeline <icann@ferdeline.com> wrote:
(Off-list)
Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me.
- Ayden
On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
Yes someone will have to pay for it.
You will. And I'll be the one that makes that happen.
Deal with it.
Sent from my iPhone
On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net> wrote:
As Robert Heinlein already correctly wrote half a century ago:
"There ain't no such thing as a free lunch"
Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another.
So why not rather find a legally compliant solution that would fit the requirements?
Volker
Am 23.03.2017 um 15:11 schrieb John Bambenek:
Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of
unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts :
Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote:
Typo materialistic should have been minimalistic
Kind regards,
Chris
------------------------------ *From: *"Chris Pelling" <chris@netearth.net> *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 23 March, 2017 12:06:01
*Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts :
- Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) - The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. - Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. - Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). - I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
------------------------------ *From: *"John Horton" <john.horton@legitscript.com> *To: *"nathalie coupet" <nathaliecoupet@yahoo.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Wednesday, 22 March, 2017 16:33:22 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*Follow LegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | Blog <http://blog.legitscript.com> | Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan < ajs@anvilwalrusden.com> wrote:
> On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: > Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. >
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ 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
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/l istinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/l istinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/l istinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
-- _________________________________ Note to self: Pillage BEFORE burning.
Allison, I agree with Volker here, the majority of registrars I know would if they had a crystal ball as to the use of the domain name would rather not register a domain if it is going to be abusive in any way. As to the cost, and other views it costs nothing and registrars are here to simply "take the money" when domains are placed on serverHold by registries, the registrar is still on the hook for the renewal costs as 1 example. Another example and like Volker, I do this part in my registrar, complaints of either whois or abuse etc I personally do, so yes, I do a lot of whois lookups too, for example, a complaint comes in, and I do a little bit of googling for common factors in the whois information we have on the domain we have a complaint against and see if other registrars have the same issue with the "registrant". So I mentioned before (and Chuck asked me to do a write-up that I still have not got around too yet - apologies to all) that registrars who care about their ICANN creds do as much as possible to quash the bad actors and domains that are held. Personally speaking this whole thread has got rather "heated" - going forward we need to calm this down as it is not getting any of us anywhere. Kind regards, Chris From: "Volker Greimann" <vgreimann@key-systems.net> To: "allison nixon" <elsakoo@gmail.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 23 March, 2017 15:37:32 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi Allison, I do not know about other registrars, I just know what I see for myself. And from that, it is impossible to generalize the relationship of domain age and abuse. Some domains are aged remain dormant for months or even years before their first abusive use while others are abused from the second they are activated. If there were a way to prevent registrations for abusive use at the time of registration, most registrars I know would be very happy to know it. V. Am 23.03.2017 um 16:31 schrieb allison nixon: So we make it opt-in. The most abused registrars almost all give free whois privacy (somehow, magically), for at least the first year, and malware domains dont usually last a year, so it changes nothing.
No deal. Sorry, but you do not get to claim to be the only source of expertise in your line of work.
I'm sure you already know this about malicious domains, as you are a renowned expert in cybersecurity and researching cybercrime. On Thu, Mar 23, 2017 at 11:20 AM, Volker Greimann < vgreimann@key-systems.net > wrote: BQ_BEGIN Imagine the moaning if we did what he proposed? Registrars activating whois privacy for everyone would all but eliminate the ability of foreign law enforcement and those in the business of fighting cybercrime as a non-authorized entity. Whois as it is today would cease to exist from one day to the next. I somehow feel that this is not what you really want. So let's try to find a solution that would maintain the essential usability of whois and at the same time remains within the confines of legal requirements. If that is an unreasonable suggestion, you can call me unreasonable. Am 23.03.2017 um 15:55 schrieb allison nixon: BQ_BEGIN The simultaneous moaning over a small whois privacy fee, with the total disregard and ignorance over current whois use cases, and the desire to destroy a company over it(oops, I mean "step on toes"), and impose various other burdens that must be borne by "someone else", because the registrars can't possibly spend a dime... bother me quite a bit more. John's tone is more than justified considering the unreasonable attitudes prevalent here. If yall are going to claim that all current use cases are not only illegal but invalid, you won't get much sympathy over raising your fees a dollar to make them "legal" again. On Thu, Mar 23, 2017 at 10:29 AM, Ayden Férdeline < icann@ferdeline.com > wrote: BQ_BEGIN (Off-list) Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me. - Ayden On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org > wrote: BQ_BEGIN Yes someone will have to pay for it. You will. And I'll be the one that makes that happen. Deal with it. Sent from my iPhone On Mar 23, 2017, at 09:18, Volker Greimann < vgreimann@key-systems.net > wrote: BQ_BEGIN As Robert Heinlein already correctly wrote half a century ago: "There ain't no such thing as a free lunch" Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another. So why not rather find a legally compliant solution that would fit the requirements? Volker Am 23.03.2017 um 15:11 schrieb John Bambenek: BQ_BEGIN Soon all of you will be forced to offer whois privacy for free. I'll leave it to you to figure out the economics. Sent from my iPhone On Mar 23, 2017, at 09:07, Volker Greimann < vgreimann@key-systems.net > wrote: BQ_BEGIN Hi Allison, BQ_BEGIN Several registrars already offer free whois privacy. They made it work, so you should keep up! Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or... Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free". TANSTAAFL. BQ_BEGIN BQ_BEGIN Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well. BQ_END I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings. BQ_END I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it. BQ_BEGIN BQ_BEGIN Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) BQ_END so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government. BQ_END Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to. BQ_BEGIN On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling < chris@netearth.net > wrote: BQ_BEGIN Typo materialistic should have been minimalistic Kind regards, Chris From: "Chris Pelling" < chris@netearth.net > To: "gnso-rds-pdp-wg" < gnso-rds-pdp-wg@icann.org > Sent: Thursday, 23 March, 2017 12:06:01 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi all, I hope everyone got home safe that attended ICANN58 :) Having just sat through and played catch up on this thread, a few things stand out to me. On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown) The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations. Some points/thoughts : * Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) * The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. * Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. * Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). * I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome. Kind regards, Chris From: "John Horton" < john.horton@legitscript.com > To: "nathalie coupet" < nathaliecoupet@yahoo.com > Cc: "gnso-rds-pdp-wg" < gnso-rds-pdp-wg@icann.org > Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript Follow Legit Script : LinkedIn | Facebook | Twitter | Blog | Google+ On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org > wrote: BQ_BEGIN +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan < ajs@anvilwalrusden.com > wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg 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 ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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. BQ_END BQ_BEGIN _______________________________________________ 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 -- 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. 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 -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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 -- _________________________________ Note to self: Pillage BEFORE burning. 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
I think you're mixing up what i said with what someone else said On Thu, Mar 23, 2017 at 12:28 PM, Chris Pelling <chris@netearth.net> wrote:
Allison,
I agree with Volker here, the majority of registrars I know would if they had a crystal ball as to the use of the domain name would rather not register a domain if it is going to be abusive in any way.
As to the cost, and other views it costs nothing and registrars are here to simply "take the money" when domains are placed on serverHold by registries, the registrar is still on the hook for the renewal costs as 1 example. Another example and like Volker, I do this part in my registrar, complaints of either whois or abuse etc I personally do, so yes, I do a lot of whois lookups too, for example, a complaint comes in, and I do a little bit of googling for common factors in the whois information we have on the domain we have a complaint against and see if other registrars have the same issue with the "registrant".
So I mentioned before (and Chuck asked me to do a write-up that I still have not got around too yet - apologies to all) that registrars who care about their ICANN creds do as much as possible to quash the bad actors and domains that are held.
Personally speaking this whole thread has got rather "heated" - going forward we need to calm this down as it is not getting any of us anywhere.
Kind regards,
Chris
------------------------------ *From: *"Volker Greimann" <vgreimann@key-systems.net> *To: *"allison nixon" <elsakoo@gmail.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 23 March, 2017 15:37:32 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi Allison,
I do not know about other registrars, I just know what I see for myself. And from that, it is impossible to generalize the relationship of domain age and abuse. Some domains are aged remain dormant for months or even years before their first abusive use while others are abused from the second they are activated.
If there were a way to prevent registrations for abusive use at the time of registration, most registrars I know would be very happy to know it.
V.
Am 23.03.2017 um 16:31 schrieb allison nixon:
So we make it opt-in. The most abused registrars almost all give free whois privacy (somehow, magically), for at least the first year, and malware domains dont usually last a year, so it changes nothing.
No deal. Sorry, but you do not get to claim to be the only source of expertise in your line of work.
I'm sure you already know this about malicious domains, as you are a renowned expert in cybersecurity and researching cybercrime.
On Thu, Mar 23, 2017 at 11:20 AM, Volker Greimann < vgreimann@key-systems.net> wrote:
Imagine the moaning if we did what he proposed? Registrars activating whois privacy for everyone would all but eliminate the ability of foreign law enforcement and those in the business of fighting cybercrime as a non-authorized entity. Whois as it is today would cease to exist from one day to the next.
I somehow feel that this is not what you really want. So let's try to find a solution that would maintain the essential usability of whois and at the same time remains within the confines of legal requirements. If that is an unreasonable suggestion, you can call me unreasonable.
Am 23.03.2017 um 15:55 schrieb allison nixon:
The simultaneous moaning over a small whois privacy fee, with the total disregard and ignorance over current whois use cases, and the desire to destroy a company over it(oops, I mean "step on toes"), and impose various other burdens that must be borne by "someone else", because the registrars can't possibly spend a dime... bother me quite a bit more. John's tone is more than justified considering the unreasonable attitudes prevalent here.
If yall are going to claim that all current use cases are not only illegal but invalid, you won't get much sympathy over raising your fees a dollar to make them "legal" again.
On Thu, Mar 23, 2017 at 10:29 AM, Ayden Férdeline <icann@ferdeline.com> wrote:
(Off-list)
Who is John Bambenek? His tone (and the lack of substance to all of his comments) really bothers me.
- Ayden
On Thu, Mar 23, 2017 at 2:24 pm, John Bambenek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
Yes someone will have to pay for it.
You will. And I'll be the one that makes that happen.
Deal with it.
Sent from my iPhone
On Mar 23, 2017, at 09:18, Volker Greimann <vgreimann@key-systems.net> wrote:
As Robert Heinlein already correctly wrote half a century ago:
"There ain't no such thing as a free lunch"
Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another.
So why not rather find a legally compliant solution that would fit the requirements?
Volker
Am 23.03.2017 um 15:11 schrieb John Bambenek:
Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of
unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts :
Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote:
Typo materialistic should have been minimalistic
Kind regards,
Chris
------------------------------ *From: *"Chris Pelling" <chris@netearth.net> *To: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 23 March, 2017 12:06:01
*Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts :
- Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) - The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. - Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. - Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). - I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
------------------------------ *From: *"John Horton" <john.horton@legitscript.com> *To: *"nathalie coupet" <nathaliecoupet@yahoo.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Wednesday, 22 March, 2017 16:33:22 *Subject: *Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
*Follow LegitScript*: LinkedIn <http://www.linkedin.com/company/legitscript-com> | Facebook <https://www.facebook.com/LegitScript> | Twitter <https://twitter.com/legitscript> | Blog <http://blog.legitscript.com> | Google+ <https://plus.google.com/112436813474708014933/posts>
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan < ajs@anvilwalrusden.com> wrote:
> On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: > Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made. >
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
______________________________ _________________ 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
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 <+49%206894%209396901> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851> Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- _________________________________ Note to self: Pillage BEFORE burning.
I have no idea who you are John, but your rude/blunt comments make me suddenly think that this WG won't go anywhere, won't get anything done, and certainly as you have now played your cards (in more than one email) goes to show that you wish to try and force ICANN to push down on its contracted parties a free service - which will never happen unless ICANN is paying for it as they will be the one that has to provide it - now, you could try that stance. But please can we have a little less arrogance and more constructive thought be simple one liners, Kind regards, Chris From: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> To: "Volker Greimann" <vgreimann@key-systems.net> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 23 March, 2017 14:24:45 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Yes someone will have to pay for it. You will. And I'll be the one that makes that happen. Deal with it. Sent from my iPhone On Mar 23, 2017, at 09:18, Volker Greimann < vgreimann@key-systems.net > wrote: As Robert Heinlein already correctly wrote half a century ago: "There ain't no such thing as a free lunch" Someone will have to pay for it. Free whois just means either the community or the customer pays for it some way or another. So why not rather find a legally compliant solution that would fit the requirements? Volker Am 23.03.2017 um 15:11 schrieb John Bambenek: BQ_BEGIN Soon all of you will be forced to offer whois privacy for free. I'll leave it to you to figure out the economics. Sent from my iPhone On Mar 23, 2017, at 09:07, Volker Greimann < vgreimann@key-systems.net > wrote: BQ_BEGIN Hi Allison, BQ_BEGIN Several registrars already offer free whois privacy. They made it work, so you should keep up! Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or... Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free". TANSTAAFL. BQ_BEGIN BQ_BEGIN Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well. BQ_END I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings. BQ_END I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it. BQ_BEGIN BQ_BEGIN Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) BQ_END so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government. BQ_END Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to. BQ_BEGIN On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling < chris@netearth.net > wrote: BQ_BEGIN Typo materialistic should have been minimalistic Kind regards, Chris From: "Chris Pelling" < chris@netearth.net > To: "gnso-rds-pdp-wg" < gnso-rds-pdp-wg@icann.org > Sent: Thursday, 23 March, 2017 12:06:01 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi all, I hope everyone got home safe that attended ICANN58 :) Having just sat through and played catch up on this thread, a few things stand out to me. On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown) The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations. Some points/thoughts : * Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) * The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. * Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. * Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). * I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome. Kind regards, Chris From: "John Horton" < john.horton@legitscript.com > To: "nathalie coupet" < nathaliecoupet@yahoo.com > Cc: "gnso-rds-pdp-wg" < gnso-rds-pdp-wg@icann.org > Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Thanks, Nathalie. I'm sure many share your frustration! I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose. Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though. John Horton President and CEO, LegitScript Follow Legit Script : LinkedIn | Facebook | Twitter | Blog | Google+ On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org > wrote: BQ_BEGIN +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home? Nathalie Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan < ajs@anvilwalrusden.com > wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg 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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg BQ_END -- _________________________________ Note to self: Pillage BEFORE burning. _______________________________________________ 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. BQ_END BQ_BEGIN _______________________________________________ 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 -- 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. BQ_END _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
So whois privacy are no longer the most evil thing? Let me quote your rant on me earlier! "Let me translate Allison's comments in the light of your mockery. You're ideas of privacy are patently absurd and your arrogance that entire industries need to rewrite how they do things to suit your effete and fantastical notions is breathtaking. Your mockery of people who investigate crime is just icing on the cake. Its not a question of looking past your own walls, its a question of whether you religious fanatics can acknowledge that other use cases are valid (or are we not part of the "all" in "better for all"). Are you really suggesting preventing spam is a higher priority than stopping human trafficking online? If someone who had need of privacy came to me for advice on registering a domain name I would tell them absolutely not to do it. Use blogspot or any other mechanism that doesn't involve a financial transaction to shield your privacy. Creating paper trails is always a poor life decision when OPSEC matters. Anything less and I would stop taking your concerns seriously. That said, we have a viable compromise, its called whois privacy protection. And it allows me to use risk based decisions on how I treat traffic to such domains. But if you wish to enable criminals to better hide so they can steal people's life savings, so they can anonymously traffic in child exploitation or to engage in sextortion against teenage girls all because you can't handle a spam filter, you can count me one that will line up against you and very publicly label you an enabler of child sexual exploitation. Then I will go to Congress, drag ICANN back under the Department of Commerce and ensure some adult supervision is had. Or you can calm the hell down and knock it off with your attitude and we can find a viable middle ground. Totally your call. And if you are really concerned about spammers, I help run investigations against them too (using whois data, in part) and could totally use the help. “ -- 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
On 23 Mar 2017, at 15:11, gnso-rds-pdp-wg@icann.org wrote:
Soon all of you will be forced to offer whois privacy for free.
I'll leave it to you to figure out the economics.
Sent from my iPhone
On Mar 23, 2017, at 09:07, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Allison,
Several registrars already offer free whois privacy. They made it work, so you should keep up!
Most such registrars still charge for the same service, it is just that the cost is hidden in their more expensive registration fees. Or they do not handle complaints appropriately. Or, or, or...
Ultimately, someone is going to pay for the service, and it is not the registrar offering it for "free".
TANSTAAFL.
Maybe dumb bad actors. Savvy bad actors just populate whois with data of unknowing third parties, thereby rendering any verification and validation instruments useless and inconveniencing the affected data subjects as well.
I'm glad you know so much about how bad actors abuse whois. But from my own limited experiences- I don't see that many input validation mechanisms on bad domains because there are a lot of "555-5555" phone numbers out there and other arbitrary strings.
I see what comes over my desk. Most domains we find involved in whois have perfectly formed and verifiable whois. The data just does not match the person who registered it.
Some points/thoughts : Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) )
so who decided that these normal uses of whois are suddenly illegal? I hereby declare my allegiance to the dark side. Down with the government.
Depends on the terms you accept when you make the whois inquiry. You may be violating the terms of the registrar or registry providing the whois service. Please note that ICANN mandates that registrars have an access agreement in place for any bulk request of whois data, most registrar apply the same rules for use of their whois data in general. And yes, registrars are free to contractually limit the uses the data they provide can be put to.
On Thu, Mar 23, 2017 at 8:16 AM, Chris Pelling <chris@netearth.net> wrote: Typo materialistic should have been minimalistic
Kind regards,
Chris
From: "Chris Pelling" <chris@netearth.net> To: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 23 March, 2017 12:06:01
Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi all,
I hope everyone got home safe that attended ICANN58 :)
Having just sat through and played catch up on this thread, a few things stand out to me.
On one side you have a stakeholder person (maybe group) advocating they will pushing for "free whois protection" provided by registrar which simply won't happen - for a number of reasons (see below), whereas the fundamental issue is what will be collected and who will be able to see it. Maybe this could be worked on from a materialistic point of view, really what does WHOIS/RDS need to show as its most basic data, I remember a discussion some months ago where Michele mentioned about simply domain name, dates of registration, expiry and DNS servers. (registrar name and abuse contact details are a given to be shown)
The storage of such data depending on "whom" the registrant and/or other contacts are located, and where it is being seen from (different jurisdiction for example) will come out further down the line in our deliberations.
Some points/thoughts : • Cost of providing the service (this includes cost of the office, personnel to run it - unless you are going to offer this free "John B" to all ICANN registrars ?) • The underlying data may not even be allowed to be provided to the whois privacy service, unless it is in the local jurisdiction of the registrant. • Harvesting and storage of whois data to be re-wrapped and sold is illegal and many registrars state this on the terms and conditions. • Gated access has to be properly defined for each gate/right of access, an example, a registrar would normally only need access to external whois for the purpose of transferring a domain name - they have no other reason to need access to this data. (registration, is totally different as it doesnt need access to the "whois") As above, storage of whois data is illegal unless it was for a lawful purpose and the only one I can think of is transfers. ICANN require registrars to keep this info for upto 2 or 7 years (cant remember which). This will step on some registrars toes as well as John H's toes whi have a business model around the supply of whois data for commercial gain (namely charging for it). • I am sorry to say that none of what the WG will do or complete will stop bad actors, they are smart, they are not dumb (well some of them are:) ) As for John H and clowns, I would gladly offer my services to help you get over that :) My issue/phobia is the dark, sadly for me that is a reality I won't be able to overcome.
Kind regards,
Chris
From: "John Horton" <john.horton@legitscript.com> To: "nathalie coupet" <nathaliecoupet@yahoo.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Wednesday, 22 March, 2017 16:33:22 Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Thanks, Nathalie. I'm sure many share your frustration!
I think that's a constructive question, and I'll jump in. My biggest fear is that in the monitoring that companies like mine do for banks, payment providers, e-commerce companies, etc. that helps determine whether a merchant is who they say they are, and whether they are engaged in other bad activity (i.e., laundering money) will be unable to obtain access to the Whois records we need in order to preserve the integrity of the payments system, protect payment providers from risk, and derivatively protect consumers. In other words, my fear is that we'll lose access to Whois records, which we need for that purpose.
Actually, to be honest, that's not true -- my biggest fear (to answer your question directly) is of clowns, and every time I travel, I ask the hotel to please check for clowns in my closet before I enter the room. But I assume you didn't really want to know my biggest fear -- you just want to know my biggest fear in relation to Whois policy, correct? Two different things, but yeah -- if a clown jumped out of my hotel closet, that would probably be the realization of my biggest fear. That's probably nothing that this working group can do much about, though.
John Horton President and CEO, LegitScript
Follow LegitScript: LinkedIn | Facebook | Twitter | Blog | Google+
On Wed, Mar 22, 2017 at 9:24 AM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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
-- _________________________________ Note to self: Pillage BEFORE burning.
_______________________________________________ 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
And let me quote you quoting my rant: "That said, we have a viable compromise, its called whois privacy protection. And it allows me to use risk based decisions on how I treat traffic to such domains. " Sent from my iPhone
On Mar 23, 2017, at 11:03, "benny@nordreg.se" <benny@nordreg.se> wrote:
That said, we have a viable compromise, its called whois privacy protection. And it allows me to use risk based decisions on how I treat traffic to such domains.
Well my suggesting was privacy by default for private persons thats where it started and I was told "You're ideas of privacy are patently absurd “ So what do you really want? Privacy, yes or no? -- 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
On 23 Mar 2017, at 17:06, John Bambenek <jcb@bambenekconsulting.com> wrote:
And let me quote you quoting my rant:
"That said, we have a viable compromise, its called whois privacy protection. And it allows me to use risk based decisions on how I treat traffic to such domains. "
Sent from my iPhone
On Mar 23, 2017, at 11:03, "benny@nordreg.se" <benny@nordreg.se> wrote:
That said, we have a viable compromise, its called whois privacy protection. And it allows me to use risk based decisions on how I treat traffic to such domains.
We cannot negotiate on legal requirements. We will not leave the trenches if doing so will expose us to legal risks. You cannot vote an illegal practice into legality. Everything else is on the table. Am 22.03.2017 um 17:24 schrieb nathalie coupet via gnso-rds-pdp-wg:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- 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.
And what legal requirements are those? You're presenting little here. On 03/23/2017 04:07 AM, Volker Greimann wrote:
We cannot negotiate on legal requirements. We will not leave the trenches if doing so will expose us to legal risks. You cannot vote an illegal practice into legality.
Everything else is on the table.
Am 22.03.2017 um 17:24 schrieb nathalie coupet via gnso-rds-pdp-wg:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Have a read at the supporting documents. You may also want to read the GPDR coming into effect next year and what it has to say about agreement and tying it to the service. I will not restate everything that is already in the basic reading materials. Am 23.03.2017 um 14:40 schrieb John Bambenek via gnso-rds-pdp-wg:
And what legal requirements are those? You're presenting little here.
On 03/23/2017 04:07 AM, Volker Greimann wrote:
We cannot negotiate on legal requirements. We will not leave the trenches if doing so will expose us to legal risks. You cannot vote an illegal practice into legality.
Everything else is on the table.
Am 22.03.2017 um 17:24 schrieb nathalie coupet via gnso-rds-pdp-wg:
+1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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.
Exactly. You offer nothing to this discussion. I have presented whois privacy for free as an option, sourced in a document in the wiki in why that works and soon once my INGO is established I will have the DP authorities tell you directly. Sent from my iPhone
On Mar 23, 2017, at 09:10, Volker Greimann <vgreimann@key-systems.net> wrote:
Have a read at the supporting documents. You may also want to read the GPDR coming into effect next year and what it has to say about agreement and tying it to the service. I will not restate everything that is already in the basic reading materials.
Am 23.03.2017 um 14:40 schrieb John Bambenek via gnso-rds-pdp-wg: And what legal requirements are those? You're presenting little here.
On 03/23/2017 04:07 AM, Volker Greimann wrote: We cannot negotiate on legal requirements. We will not leave the trenches if doing so will expose us to legal risks. You cannot vote an illegal practice into legality.
Everything else is on the table.
Am 22.03.2017 um 17:24 schrieb nathalie coupet via gnso-rds-pdp-wg: +1 I must say I'm a bit disillusioned by the entire process. This PDP should look like a negotiating table, instead it is more like a War of Trenches. If stakeholders are not motivated to negotiate, there is no sense of urgency and stakes for change are so low, then I wonder what we are doing here in the first place. Could every stakeholder state what their biggest fear is, and we could try to avoid their realization? Or maybe, in last resort, we should just vote for the best proposal and go home?
Nathalie
Sent from my iPhone
On Mar 22, 2017, at 12:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 22, 2017 at 10:19:56AM -0500, John Bambenek wrote: Yes there is a difference which is why I am using both words. And that's why I am suggesting we talking about optional and maskable fields right up front as part of the requirements discussion not some ancillary discussion that happens later after all the decisions are already made.
I thought the WG had already decided on a different (multi-pass) strategy, in which data collection itself was treated first with the principle that, if there were some (legitmate, hand-wave hand-wave) purpose then collection would be considered. Later, the further question of access to such collected items would be taken up.
I don't really care which way we do this, but it seems to me that we need to stop arguing about the way by which we'll reach a result and start actually doing work in the direction of some result. The meta-discussions about process are wearing out contributors (well, at least one contributor!) and creating the condition in which those who want no changes at all will get their way by exhaustion. If ICANN is incapable of coming to terms with the deficiencies of whois (the protocol) after all this time, it will be revealed to be ridiculous.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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
allison nixon wrote:
I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well.
I agree with this. Additionally, I find it somewhat dubious when a corporation attempts to cloak itself in privacy protection designed for natural persons. -- Denny Watson Sr. Investigator The Spamhaus Project
Although there can be many valid reasons for such uses. Even the largest corporations use whois privacy or similar services for a bunch of legitimate purposes such as not wanting the name of a new product or service to leak prematurely. V. Am 25.03.2017 um 00:04 schrieb Denny Watson:
allison nixon wrote:
I find myself in agreement with the free whois privacy idea. It renders a lot of these privacy concerns moot, and it isn't a big leap to make because many registrars already offer it for free. It also won't break the many security systems used by companies and law enforcement every day. It will also resolve the spam issue. And it does seem that giving users a true, zero-cost, choice as to how they want their data disseminated will resolve a lot of the legal issues as well. I agree with this. Additionally, I find it somewhat dubious when a corporation attempts to cloak itself in privacy protection designed for natural persons.
-- 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.
Much of the background in this discussion has reflected on the European approach to data privacy. It is worth noting the U.S. government is planning a 180 degree reversal on data privacy in the U.S. See: https://www.theguardian.com/commentisfree/2017/mar/26/internet-deregulation-... Sam L (npoc)
I hope to clear up this misconception: > The practice of charging someone extra for the use of their privacy rights (and for the registrar to do less work) is the pathological business model at the center of all of this. Registrars are not charging their customers extra for use of their privacy rights, they are charging extra for a value added service: - provision of alternate address data - assumption of legal risks involved in being listed as registered name holder for a third party domain - forwarding of email - staffing of abuse team to handle and review any incoming communications - compliance with all requirements of whois privacy spec of the RAA. and much much more. At this point, provision of ICANN compliant whois privacy service costs money and that money is passed on to the parties using that service. TANSTAAFL -- 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, On Tue, Mar 21, 2017 at 06:06:07PM +0000, Gomes, Chuck wrote:
Do you think that we need to develop a purpose for every data element in the RDS or would it suffice to develop a purpose for collection of RDS data elements, a purpose for public display of RDS data elements and a purpose for gated access to RDS data elements?
The experts last week suggested that each element needs to be evaluated. I fear the size of that rat-hole, however, and wonder whether it might not be enough to use classes.
If we considered data elements by class, what would you suggest are the classes?
Well, I suggested some here for the thin data. These turn out to be simple cases because they're all pretty much necessarily public for the functioning of the system at all (that is, if one is going to argue that one of the thin elements ought to be private, one is in effect arguing that we should not have an RDS. That's ok, but it's a different argument.) For the other data, we have several different classes of contact information: the identity of the contact in question, the street address, phone number, and email address, and fax numbers (because everyone is using 1980s tech for communications now ;-) ). This contact info seems to me to be one dimension of the issues. The second dimension is the purpose of the contact itself: what is that contact information for? The purpose of the technical contact, for instance, is bound to be different from the admin or registrant contact data. So, I would propose first going through the contact data with the purpose-of-having-that-contact filter. Then we could discuss the disclosure of the different items I mention above. A -- Andrew Sullivan ajs@anvilwalrusden.com
I don't recall them saying we need a purpose for every data element but I think they said we need a purpose for collection and a different purpose for public access, etc. I could be wrong. We do need to clarify. Chuck Sent from my iPhone
On Mar 21, 2017, at 2:53 PM, "ajs@anvilwalrusden.com" <ajs@anvilwalrusden.com> wrote:
Hi,
On Tue, Mar 21, 2017 at 06:06:07PM +0000, Gomes, Chuck wrote: Do you think that we need to develop a purpose for every data element in the RDS or would it suffice to develop a purpose for collection of RDS data elements, a purpose for public display of RDS data elements and a purpose for gated access to RDS data elements?
The experts last week suggested that each element needs to be evaluated. I fear the size of that rat-hole, however, and wonder whether it might not be enough to use classes.
If we considered data elements by class, what would you suggest are the classes?
Well, I suggested some here for the thin data. These turn out to be simple cases because they're all pretty much necessarily public for the functioning of the system at all (that is, if one is going to argue that one of the thin elements ought to be private, one is in effect arguing that we should not have an RDS. That's ok, but it's a different argument.)
For the other data, we have several different classes of contact information: the identity of the contact in question, the street address, phone number, and email address, and fax numbers (because everyone is using 1980s tech for communications now ;-) ). This contact info seems to me to be one dimension of the issues. The second dimension is the purpose of the contact itself: what is that contact information for? The purpose of the technical contact, for instance, is bound to be different from the admin or registrant contact data. So, I would propose first going through the contact data with the purpose-of-having-that-contact filter. Then we could discuss the disclosure of the different items I mention above.
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
I support this suggestion/framework. I could be swayed that the Date publication is not really public information so I’m interested in other points of view. Jim On 20 Mar 2017, at 18:21, Andrew Sullivan wrote:
Hi,
I left the meeting with data protection experts last week feeling quite strongly the need for a specific and concrete purpose for each datum we recommend to collect and to make available; and the need for a definition of who the maximal (appropriate) audience is (given the purpose).
At the same time, I think that a reasonably short and high-level statement of purpose along the lines that we have been preparing can provide a useful set of principles.
It strikes me that maybe we could take the high-level purpose statement, and go through some potential data elements and link each one concretely to at least one of the principles in our candidate list. In what follows I name these "purpose 1", "purpose 2", &c. The purposes are numbered according to the scheme in RDS PDP Phase 1: Key Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware that the details in the candidate list are still in flux, but I think the broad strokes are pretty close anyway, so I thought I'd try it with the "thin" data we agreed to start with. This mail is a little long because I'm dealing with all the classes of elements in one message. I suppose we could break this into one-thread-per-element (or class) if we don't converge quickly on each of them. The outline below is just my view, of course, though obviously I think that what I say is true. I use the "maximal audience" because I think that if there is any "whole public" use then there's no point considering more restrictive uses. (For instance, if we need the domain name to be published to everyone on the Internet because it won't work otherwise, then it makes no difference if LEOs want that data under some sort of authorized-access protocol, because they'll just get it under the wide-open rules instead. So we don't need to care about the LEO purpose in that case.) "Maximal audience" might not work for cases where two different classes have different needs both of which require some restrictions, but it's handy here because we're talking about thin data.
I'm sorry this is long, but I hope it is a useful contribution to the discussion.
Best regards,
A
---%<---cut here---
Here is a convenient example thin whois response, in case anyone wants it to for reference in what follows. (Among other things, it reminds me that something I started to do has never been completed, so thank you to this WG for reminding me of that. :-) )
Domain Name: ANVILWALRUSDEN.COM Registrar: TUCOWS DOMAINS INC. Sponsoring Registrar IANA ID: 69 Whois Server: whois.tucows.com Referral URL: http://www.tucowsdomains.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Updated Date: 17-jan-2017 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017
1. DOMAIN NAME ---------------
a. Collection
The domain name is required to be collected under purpose 1. Without this, there is no domain name, so it is literally impossible to have anything to collect or publish.
b. Publication
The domain name is required to be published under purpose 1, because it is a key by which data is accessed. If you wish to look up the current data about a particular name, you use the name as the key by which you query. (This is not the only possible key. For instance, in an EPP registry you could in principle use the ROID to look up a particular name object. But that does not give you the current data for the thing so named; it just gives you the data about that Repository Object. Two different versions of the same name -- like if example.com is registered by Alice then deleted and later registered by Bob -- have different ROIDs.)
c. Maximal audience
The data audience is Internet-wide under purpose 1 or purpose 2 (or both). The domain name is by definition not private data, because domain names registered in DNS domain name registries (i.e. every registry possibly covered by ICANN policy -- the registries subordinate to the IANA DNS name registries) are name registration in a public name space. Note that it is not possible to keep the existence of a name private, because even if a name were initially undisclosed its existence would be disclosed whenever someone else tried to register it.
2. REGISTRAR IDENTITY -------------------
There are four items here, but three classes of data. The (i) registrar ID provides data about the entity that created the entry in the registry (formally, in EPP, "repository"). The (ii) Whois Server and Referral URL both provide metadata necessary for the operation of the distributed database that makes up the RDS (in systems other than whois, approximately the same data with the same relation to identity would be in place, but the details might be different. I think we can treat this as a class anyway). Finally, IANA has a registry of registrar IDs (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), and that contains their (iii) names. This is a protocol parameter registry, but it appears to be managed by ICANN so it is probably appropriate for this PDP to make the policy about how that is to be managed.
a. Collection
Data (i) and (ii) are all required to be collected under purposes 1 and 2. Without this data it is not possible to know the source of the data and it is not possible to trace it further in the system. Data (iii) needs to be collected in order to give (i) meaning, because it is the only way to know whether two IANA ids are bound to the same organization or person.
b. Publication
Data (i) are possibly required to be published under purpose 1. This largely depends on whether we think the identity of who is managing an object in the registry is part of the "lifecycle of a domain name". My feeling is "yes". Also, this information is likely to be disclosed anyway; see below.
Data (ii) are required to be published under purposes 1 and 2, as long as there is at least one data element that is required under some purpose and is not available from the registry. (Since the actual registration life cycle is controlled by the registrar and not the registry, this appears likely.) Owing to the way these work, publication of these is likely to "leak" information about (i) or (iii) also.
c. Maximal audience
Given purposes 2 and 3 and probably 5, and since the source of contact information is registrars, the maximal audience is probably everyone on the Internet. If we think that purposes 2, 3, or 5 are limited in respect of who needs to make such contact or who needs to check accuracy, then the maximal audience is the set of all those who have such a need. It's worth observing, however, that at least the technical contact for a name ought to be contactable by anyone on the Internet, since when we want to "facilitate communication with domain contacts" at least part of the reason is as a fallback when a site breaks in some way. (This may suggest that we need to unpack the details of purpose 3.)
3. NAME SERVERS ---------------
a. Collection
Without collecting the name servers, domain names cannot function on the Internet, so this is required under purposes 1 and 2. (Given that the registration of the name itself and the collection of the name servers are both required for the basic functioning of the Internet Domain Name System, it strikes me that we may be missing a more obvious purpose in our list, but I guess (1) and (2) will be enough and we're already so late that I am loathe to suggest something more.)
b. Publication
Whenever a name is available on the Internet, the name server data is already available in the DNS, so this data is necessarily published. Under either purpose 1 or 2 (or both), the data about nameservers in the RDS provides an avenue for troubleshooting issues in the DNS, and so it is required for those purposes.
c. Maximal audience
Anyone who wants to access a site must be able to find this data in the DNS. Potentially anyone who has a problem with resolution can use the data in the RDS to aid in troubleshooting, so the audience under purpose 1 or 2 (or both) is everyone on the Internet.
4. STATUS VALUES ----------------
a. Collection
The status values are not exactly "collected", but are at least in part the result of various actions by the sponsoring registrar and registry on the name. (Some can be set directly.) These govern the disposition of the name in question, and are a necessary condition for having a shared registration system, so they are required under purpose 1.
b. Publication
The status values govern the possible things that could be done to a name, and therefore the data must be published under purpose 1.
c. Maximal audience
At leasr some status values are required for doing some troubleshooting of resolution failures, so the audience for at least some values under purposes 1 or 2 is "everyone on the Internet". It is possible to argue that some of the status values are relevant only to those people who wish to perform some actions on the domain (such as transferring) or people in a position to do some kinds of activity (such as updating contact information). If we really think it necessary, we could undertake the exercise of audience evaluation for each EPP status.
5. DATES ---------
While the dates might appear to be different kinds, they aren't, since for our purposes they all have at least one common utility (see below).
a. Collection
The dates, like status values, are not exactly "collected": they're a consequence of certain activities. They're necessary for the workings of the shared registration systems using the current fee-for-term model that (approximately?) all gTLD registries use today, so they're required under purpose 1.
b. Publication
The dates are required under purpose 1 or 2 in order to aid troubleshooting of resolution. (If a name worked yesterday and not today, it is helpful to know that it was just created -- meaning the old one was deleted -- or that it is expired, or that someone updated the name only last night.)
c. Maximal audience
Because of the troubleshooting aspects of these dates, the audience under purpose 1 or 2 is everyone on the Internet.
-- 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
Hi I agree that this is a nice framework and want to thank Andrew for putting this together. Having concrete written proposals such as this to discuss/debate is IMO important to ensure we make good progress. It is not clear however we will need this level of detail/specificity in whatever the “end product” of our purpose discussion may be but believe the analysis is useful to move the ball forward. Thanks. Alex On 3/28/17, 9:09 AM, <gnso-rds-pdp-wg-bounces@icann.org on behalf of jgalvin@afilias.info> wrote: I support this suggestion/framework. I could be swayed that the Date publication is not really public information so I’m interested in other points of view. Jim On 20 Mar 2017, at 18:21, Andrew Sullivan wrote: > Hi, > > I left the meeting with data protection experts last week feeling > quite strongly the need for a specific and concrete purpose for each > datum we recommend to collect and to make available; and the need for > a definition of who the maximal (appropriate) audience is (given the > purpose). > > At the same time, I think that a reasonably short and high-level > statement of purpose along the lines that we have been preparing can > provide a useful set of principles. > > It strikes me that maybe we could take the high-level purpose > statement, and go through some potential data elements and link each > one concretely to at least one of the principles in our candidate > list. In what follows I name these "purpose 1", "purpose 2", &c. The > purposes are numbered according to the scheme in RDS PDP Phase 1: Key > Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware > that the details in the candidate list are still in flux, but I think > the broad strokes are pretty close anyway, so I thought I'd try it > with the "thin" data we agreed to start with. This mail is a little > long because I'm dealing with all the classes of elements in one > message. I suppose we could break this into one-thread-per-element > (or class) if we don't converge quickly on each of them. The outline > below is just my view, of course, though obviously I think that what I > say is true. I use the "maximal audience" because I think that if > there is any "whole public" use then there's no point considering more > restrictive uses. (For instance, if we need the domain name to be > published to everyone on the Internet because it won't work otherwise, > then it makes no difference if LEOs want that data under some sort of > authorized-access protocol, because they'll just get it under the > wide-open rules instead. So we don't need to care about the LEO > purpose in that case.) "Maximal audience" might not work for cases > where two different classes have different needs both of which require > some restrictions, but it's handy here because we're talking about > thin data. > > I'm sorry this is long, but I hope it is a useful contribution to the > discussion. > > Best regards, > > A > > ---%<---cut here--- > > Here is a convenient example thin whois response, in case anyone wants > it to for reference in what follows. (Among other things, it reminds > me > that something I started to do has never been completed, so thank you > to this WG for reminding me of that. :-) ) > > Domain Name: ANVILWALRUSDEN.COM > Registrar: TUCOWS DOMAINS INC. > Sponsoring Registrar IANA ID: 69 > Whois Server: whois.tucows.com > Referral URL: http://www.tucowsdomains.com > Name Server: NS1.SYSTEMDNS.COM > Name Server: NS2.SYSTEMDNS.COM > Name Server: NS3.SYSTEMDNS.COM > Status: clientTransferProhibited > https://icann.org/epp#clientTransferProhibited > Status: clientUpdateProhibited > https://icann.org/epp#clientUpdateProhibited > Updated Date: 17-jan-2017 > Creation Date: 30-jun-2010 > Expiration Date: 30-jun-2017 > > > 1. DOMAIN NAME > --------------- > > a. Collection > > The domain name is required to be collected under purpose 1. Without > this, there is no domain name, so it is literally impossible to have > anything to collect or publish. > > b. Publication > > The domain name is required to be published under purpose 1, because > it is a key by which data is accessed. If you wish to look up the > current data about a particular name, you use the name as the key by > which you query. (This is not the only possible key. For instance, > in an EPP registry you could in principle use the ROID to look up a > particular name object. But that does not give you the current data > for the thing so named; it just gives you the data about that > Repository Object. Two different versions of the same name -- like if > example.com is registered by Alice then deleted and later registered > by Bob -- have different ROIDs.) > > c. Maximal audience > > The data audience is Internet-wide under purpose 1 or purpose 2 (or > both). The domain name is by definition not private data, because > domain names registered in DNS domain name registries (i.e. every > registry possibly covered by ICANN policy -- the registries > subordinate to the IANA DNS name registries) are name registration in > a public name space. Note that it is not possible to keep the > existence of a name private, because even if a name were initially > undisclosed its existence would be disclosed whenever someone else > tried to register it. > > 2. REGISTRAR IDENTITY > ------------------- > > There are four items here, but three classes of data. The (i) > registrar ID provides data about the entity that created the entry in > the registry (formally, in EPP, "repository"). The (ii) Whois Server > and Referral URL both provide metadata necessary for the operation of > the distributed database that makes up the RDS (in systems other than > whois, approximately the same data with the same relation to identity > would be in place, but the details might be different. I think we can > treat this as a class anyway). Finally, IANA has a registry of > registrar IDs > (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), > and that contains their (iii) names. This is a protocol parameter > registry, but it appears to be managed by ICANN so it is probably > appropriate for this PDP to make the policy about how that is to be > managed. > > a. Collection > > Data (i) and (ii) are all required to be collected under purposes 1 > and 2. Without this data it is not possible to know the source of the > data and it is not possible to trace it further in the system. Data > (iii) needs to be collected in order to give (i) meaning, because it > is the only way to know whether two IANA ids are bound to the same > organization or person. > > b. Publication > > Data (i) are possibly required to be published under purpose 1. This > largely depends on whether we think the identity of who is managing an > object in the registry is part of the "lifecycle of a domain name". > My feeling is "yes". Also, this information is likely to be disclosed > anyway; see below. > > Data (ii) are required to be published under purposes 1 and 2, as long > as there is at least one data element that is required under some > purpose and is not available from the registry. (Since the actual > registration life cycle is controlled by the registrar and not the > registry, this appears likely.) Owing to the way these work, > publication of these is likely to "leak" information about (i) or > (iii) also. > > c. Maximal audience > > Given purposes 2 and 3 and probably 5, and since the source of contact > information is registrars, the maximal audience is probably everyone > on the Internet. If we think that purposes 2, 3, or 5 are limited in > respect of who needs to make such contact or who needs to check > accuracy, then the maximal audience is the set of all those who have > such a need. It's worth observing, however, that at least the > technical contact for a name ought to be contactable by anyone on the > Internet, since when we want to "facilitate communication with domain > contacts" at least part of the reason is as a fallback when a site > breaks in some way. (This may suggest that we need to unpack the > details of purpose 3.) > > 3. NAME SERVERS > --------------- > > a. Collection > > Without collecting the name servers, domain names cannot function on > the Internet, so this is required under purposes 1 and 2. (Given that > the registration of the name itself and the collection of the name > servers are both required for the basic functioning of the Internet > Domain Name System, it strikes me that we may be missing a more > obvious purpose in our list, but I guess (1) and (2) will be enough > and we're already so late that I am loathe to suggest something more.) > > b. Publication > > Whenever a name is available on the Internet, the name server data is > already available in the DNS, so this data is necessarily published. > Under either purpose 1 or 2 (or both), the data about nameservers in > the RDS provides an avenue for troubleshooting issues in the DNS, and > so it is required for those purposes. > > c. Maximal audience > > Anyone who wants to access a site must be able to find this data in > the DNS. Potentially anyone who has a problem with resolution can use > the data in the RDS to aid in troubleshooting, so the audience under > purpose 1 or 2 (or both) is everyone on the Internet. > > 4. STATUS VALUES > ---------------- > > a. Collection > > The status values are not exactly "collected", but are at least in > part the result of various actions by the sponsoring registrar and > registry on the name. (Some can be set directly.) These govern the > disposition of the name in question, and are a necessary condition for > having a shared registration system, so they are required under > purpose 1. > > b. Publication > > The status values govern the possible things that could be done to a > name, and therefore the data must be published under purpose 1. > > c. Maximal audience > > At leasr some status values are required for doing some > troubleshooting of resolution failures, so the audience for at least > some values under purposes 1 or 2 is "everyone on the Internet". It > is possible to argue that some of the status values are relevant only > to those people who wish to perform some actions on the domain (such > as transferring) or people in a position to do some kinds of activity > (such as updating contact information). If we really think it > necessary, we could undertake the exercise of audience evaluation for > each EPP status. > > 5. DATES > --------- > > While the dates might appear to be different kinds, they aren't, since > for our purposes they all have at least one common utility (see > below). > > a. Collection > > The dates, like status values, are not exactly "collected": they're a > consequence of certain activities. They're necessary for the workings > of the shared registration systems using the current fee-for-term > model that (approximately?) all gTLD registries use today, so they're > required under purpose 1. > > b. Publication > > The dates are required under purpose 1 or 2 in order to aid > troubleshooting of resolution. (If a name worked yesterday and not > today, it is helpful to know that it was just created -- meaning the > old one was deleted -- or that it is expired, or that someone updated > the name only last night.) > > c. Maximal audience > > Because of the troubleshooting aspects of these dates, the audience > under purpose 1 or 2 is everyone on the Internet. > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Thanks for the feedback Alex. I am not sure whether we need that much detail either but we can always back off the level of detail if we decided that is best. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Deacon, Alex Sent: Tuesday, March 28, 2017 10:31 AM To: James Galvin <jgalvin@afilias.info>; Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Hi I agree that this is a nice framework and want to thank Andrew for putting this together. Having concrete written proposals such as this to discuss/debate is IMO important to ensure we make good progress. It is not clear however we will need this level of detail/specificity in whatever the “end product” of our purpose discussion may be but believe the analysis is useful to move the ball forward. Thanks. Alex On 3/28/17, 9:09 AM, <gnso-rds-pdp-wg-bounces@icann.org on behalf of jgalvin@afilias.info> wrote: I support this suggestion/framework. I could be swayed that the Date publication is not really public information so I’m interested in other points of view. Jim On 20 Mar 2017, at 18:21, Andrew Sullivan wrote: > Hi, > > I left the meeting with data protection experts last week feeling > quite strongly the need for a specific and concrete purpose for each > datum we recommend to collect and to make available; and the need for > a definition of who the maximal (appropriate) audience is (given the > purpose). > > At the same time, I think that a reasonably short and high-level > statement of purpose along the lines that we have been preparing can > provide a useful set of principles. > > It strikes me that maybe we could take the high-level purpose > statement, and go through some potential data elements and link each > one concretely to at least one of the principles in our candidate > list. In what follows I name these "purpose 1", "purpose 2", &c. The > purposes are numbered according to the scheme in RDS PDP Phase 1: Key > Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware > that the details in the candidate list are still in flux, but I think > the broad strokes are pretty close anyway, so I thought I'd try it > with the "thin" data we agreed to start with. This mail is a little > long because I'm dealing with all the classes of elements in one > message. I suppose we could break this into one-thread-per-element > (or class) if we don't converge quickly on each of them. The outline > below is just my view, of course, though obviously I think that what I > say is true. I use the "maximal audience" because I think that if > there is any "whole public" use then there's no point considering more > restrictive uses. (For instance, if we need the domain name to be > published to everyone on the Internet because it won't work otherwise, > then it makes no difference if LEOs want that data under some sort of > authorized-access protocol, because they'll just get it under the > wide-open rules instead. So we don't need to care about the LEO > purpose in that case.) "Maximal audience" might not work for cases > where two different classes have different needs both of which require > some restrictions, but it's handy here because we're talking about > thin data. > > I'm sorry this is long, but I hope it is a useful contribution to the > discussion. > > Best regards, > > A > > ---%<---cut here--- > > Here is a convenient example thin whois response, in case anyone wants > it to for reference in what follows. (Among other things, it reminds > me > that something I started to do has never been completed, so thank you > to this WG for reminding me of that. :-) ) > > Domain Name: ANVILWALRUSDEN.COM > Registrar: TUCOWS DOMAINS INC. > Sponsoring Registrar IANA ID: 69 > Whois Server: whois.tucows.com > Referral URL: http://www.tucowsdomains.com > Name Server: NS1.SYSTEMDNS.COM > Name Server: NS2.SYSTEMDNS.COM > Name Server: NS3.SYSTEMDNS.COM > Status: clientTransferProhibited > https://icann.org/epp#clientTransferProhibited > Status: clientUpdateProhibited > https://icann.org/epp#clientUpdateProhibited > Updated Date: 17-jan-2017 > Creation Date: 30-jun-2010 > Expiration Date: 30-jun-2017 > > > 1. DOMAIN NAME > --------------- > > a. Collection > > The domain name is required to be collected under purpose 1. Without > this, there is no domain name, so it is literally impossible to have > anything to collect or publish. > > b. Publication > > The domain name is required to be published under purpose 1, because > it is a key by which data is accessed. If you wish to look up the > current data about a particular name, you use the name as the key by > which you query. (This is not the only possible key. For instance, > in an EPP registry you could in principle use the ROID to look up a > particular name object. But that does not give you the current data > for the thing so named; it just gives you the data about that > Repository Object. Two different versions of the same name -- like if > example.com is registered by Alice then deleted and later registered > by Bob -- have different ROIDs.) > > c. Maximal audience > > The data audience is Internet-wide under purpose 1 or purpose 2 (or > both). The domain name is by definition not private data, because > domain names registered in DNS domain name registries (i.e. every > registry possibly covered by ICANN policy -- the registries > subordinate to the IANA DNS name registries) are name registration in > a public name space. Note that it is not possible to keep the > existence of a name private, because even if a name were initially > undisclosed its existence would be disclosed whenever someone else > tried to register it. > > 2. REGISTRAR IDENTITY > ------------------- > > There are four items here, but three classes of data. The (i) > registrar ID provides data about the entity that created the entry in > the registry (formally, in EPP, "repository"). The (ii) Whois Server > and Referral URL both provide metadata necessary for the operation of > the distributed database that makes up the RDS (in systems other than > whois, approximately the same data with the same relation to identity > would be in place, but the details might be different. I think we can > treat this as a class anyway). Finally, IANA has a registry of > registrar IDs > (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), > and that contains their (iii) names. This is a protocol parameter > registry, but it appears to be managed by ICANN so it is probably > appropriate for this PDP to make the policy about how that is to be > managed. > > a. Collection > > Data (i) and (ii) are all required to be collected under purposes 1 > and 2. Without this data it is not possible to know the source of the > data and it is not possible to trace it further in the system. Data > (iii) needs to be collected in order to give (i) meaning, because it > is the only way to know whether two IANA ids are bound to the same > organization or person. > > b. Publication > > Data (i) are possibly required to be published under purpose 1. This > largely depends on whether we think the identity of who is managing an > object in the registry is part of the "lifecycle of a domain name". > My feeling is "yes". Also, this information is likely to be disclosed > anyway; see below. > > Data (ii) are required to be published under purposes 1 and 2, as long > as there is at least one data element that is required under some > purpose and is not available from the registry. (Since the actual > registration life cycle is controlled by the registrar and not the > registry, this appears likely.) Owing to the way these work, > publication of these is likely to "leak" information about (i) or > (iii) also. > > c. Maximal audience > > Given purposes 2 and 3 and probably 5, and since the source of contact > information is registrars, the maximal audience is probably everyone > on the Internet. If we think that purposes 2, 3, or 5 are limited in > respect of who needs to make such contact or who needs to check > accuracy, then the maximal audience is the set of all those who have > such a need. It's worth observing, however, that at least the > technical contact for a name ought to be contactable by anyone on the > Internet, since when we want to "facilitate communication with domain > contacts" at least part of the reason is as a fallback when a site > breaks in some way. (This may suggest that we need to unpack the > details of purpose 3.) > > 3. NAME SERVERS > --------------- > > a. Collection > > Without collecting the name servers, domain names cannot function on > the Internet, so this is required under purposes 1 and 2. (Given that > the registration of the name itself and the collection of the name > servers are both required for the basic functioning of the Internet > Domain Name System, it strikes me that we may be missing a more > obvious purpose in our list, but I guess (1) and (2) will be enough > and we're already so late that I am loathe to suggest something more.) > > b. Publication > > Whenever a name is available on the Internet, the name server data is > already available in the DNS, so this data is necessarily published. > Under either purpose 1 or 2 (or both), the data about nameservers in > the RDS provides an avenue for troubleshooting issues in the DNS, and > so it is required for those purposes. > > c. Maximal audience > > Anyone who wants to access a site must be able to find this data in > the DNS. Potentially anyone who has a problem with resolution can use > the data in the RDS to aid in troubleshooting, so the audience under > purpose 1 or 2 (or both) is everyone on the Internet. > > 4. STATUS VALUES > ---------------- > > a. Collection > > The status values are not exactly "collected", but are at least in > part the result of various actions by the sponsoring registrar and > registry on the name. (Some can be set directly.) These govern the > disposition of the name in question, and are a necessary condition for > having a shared registration system, so they are required under > purpose 1. > > b. Publication > > The status values govern the possible things that could be done to a > name, and therefore the data must be published under purpose 1. > > c. Maximal audience > > At leasr some status values are required for doing some > troubleshooting of resolution failures, so the audience for at least > some values under purposes 1 or 2 is "everyone on the Internet". It > is possible to argue that some of the status values are relevant only > to those people who wish to perform some actions on the domain (such > as transferring) or people in a position to do some kinds of activity > (such as updating contact information). If we really think it > necessary, we could undertake the exercise of audience evaluation for > each EPP status. > > 5. DATES > --------- > > While the dates might appear to be different kinds, they aren't, since > for our purposes they all have at least one common utility (see > below). > > a. Collection > > The dates, like status values, are not exactly "collected": they're a > consequence of certain activities. They're necessary for the workings > of the shared registration systems using the current fee-for-term > model that (approximately?) all gTLD registries use today, so they're > required under purpose 1. > > b. Publication > > The dates are required under purpose 1 or 2 in order to aid > troubleshooting of resolution. (If a name worked yesterday and not > today, it is helpful to know that it was just created -- meaning the > old one was deleted -- or that it is expired, or that someone updated > the name only last night.) > > c. Maximal audience > > Because of the troubleshooting aspects of these dates, the audience > under purpose 1 or 2 is everyone on the Internet. > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > gnso-rds-pdp-wg mailing list > gnso-rds-pdp-wg@icann.org > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
My read of previous legal reviews is that information that is mandatory where the consumer cannot control privacy are those that will need the most justification. Optional or maskable fields or information on entities/corporations require much less scrutiny. Sent from my iPhone
On Mar 28, 2017, at 10:50, Gomes, Chuck via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
Thanks for the feedback Alex. I am not sure whether we need that much detail either but we can always back off the level of detail if we decided that is best.
Chuck
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Deacon, Alex Sent: Tuesday, March 28, 2017 10:31 AM To: James Galvin <jgalvin@afilias.info>; Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail"
Hi
I agree that this is a nice framework and want to thank Andrew for putting this together. Having concrete written proposals such as this to discuss/debate is IMO important to ensure we make good progress.
It is not clear however we will need this level of detail/specificity in whatever the “end product” of our purpose discussion may be but believe the analysis is useful to move the ball forward.
Thanks. Alex
On 3/28/17, 9:09 AM, <gnso-rds-pdp-wg-bounces@icann.org on behalf of jgalvin@afilias.info> wrote:
I support this suggestion/framework.
I could be swayed that the Date publication is not really public information so I’m interested in other points of view.
Jim
On 20 Mar 2017, at 18:21, Andrew Sullivan wrote:
Hi,
I left the meeting with data protection experts last week feeling quite strongly the need for a specific and concrete purpose for each datum we recommend to collect and to make available; and the need for a definition of who the maximal (appropriate) audience is (given the purpose).
At the same time, I think that a reasonably short and high-level statement of purpose along the lines that we have been preparing can provide a useful set of principles.
It strikes me that maybe we could take the high-level purpose statement, and go through some potential data elements and link each one concretely to at least one of the principles in our candidate list. In what follows I name these "purpose 1", "purpose 2", &c. The purposes are numbered according to the scheme in RDS PDP Phase 1: Key Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware that the details in the candidate list are still in flux, but I think the broad strokes are pretty close anyway, so I thought I'd try it with the "thin" data we agreed to start with. This mail is a little long because I'm dealing with all the classes of elements in one message. I suppose we could break this into one-thread-per-element (or class) if we don't converge quickly on each of them. The outline below is just my view, of course, though obviously I think that what I say is true. I use the "maximal audience" because I think that if there is any "whole public" use then there's no point considering more restrictive uses. (For instance, if we need the domain name to be published to everyone on the Internet because it won't work otherwise, then it makes no difference if LEOs want that data under some sort of authorized-access protocol, because they'll just get it under the wide-open rules instead. So we don't need to care about the LEO purpose in that case.) "Maximal audience" might not work for cases where two different classes have different needs both of which require some restrictions, but it's handy here because we're talking about thin data.
I'm sorry this is long, but I hope it is a useful contribution to the discussion.
Best regards,
A
---%<---cut here---
Here is a convenient example thin whois response, in case anyone wants it to for reference in what follows. (Among other things, it reminds me that something I started to do has never been completed, so thank you to this WG for reminding me of that. :-) )
Domain Name: ANVILWALRUSDEN.COM Registrar: TUCOWS DOMAINS INC. Sponsoring Registrar IANA ID: 69 Whois Server: whois.tucows.com Referral URL: http://www.tucowsdomains.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Updated Date: 17-jan-2017 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017
1. DOMAIN NAME ---------------
a. Collection
The domain name is required to be collected under purpose 1. Without this, there is no domain name, so it is literally impossible to have anything to collect or publish.
b. Publication
The domain name is required to be published under purpose 1, because it is a key by which data is accessed. If you wish to look up the current data about a particular name, you use the name as the key by which you query. (This is not the only possible key. For instance, in an EPP registry you could in principle use the ROID to look up a particular name object. But that does not give you the current data for the thing so named; it just gives you the data about that Repository Object. Two different versions of the same name -- like if example.com is registered by Alice then deleted and later registered by Bob -- have different ROIDs.)
c. Maximal audience
The data audience is Internet-wide under purpose 1 or purpose 2 (or both). The domain name is by definition not private data, because domain names registered in DNS domain name registries (i.e. every registry possibly covered by ICANN policy -- the registries subordinate to the IANA DNS name registries) are name registration in a public name space. Note that it is not possible to keep the existence of a name private, because even if a name were initially undisclosed its existence would be disclosed whenever someone else tried to register it.
2. REGISTRAR IDENTITY -------------------
There are four items here, but three classes of data. The (i) registrar ID provides data about the entity that created the entry in the registry (formally, in EPP, "repository"). The (ii) Whois Server and Referral URL both provide metadata necessary for the operation of the distributed database that makes up the RDS (in systems other than whois, approximately the same data with the same relation to identity would be in place, but the details might be different. I think we can treat this as a class anyway). Finally, IANA has a registry of registrar IDs (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar...), and that contains their (iii) names. This is a protocol parameter registry, but it appears to be managed by ICANN so it is probably appropriate for this PDP to make the policy about how that is to be managed.
a. Collection
Data (i) and (ii) are all required to be collected under purposes 1 and 2. Without this data it is not possible to know the source of the data and it is not possible to trace it further in the system. Data (iii) needs to be collected in order to give (i) meaning, because it is the only way to know whether two IANA ids are bound to the same organization or person.
b. Publication
Data (i) are possibly required to be published under purpose 1. This largely depends on whether we think the identity of who is managing an object in the registry is part of the "lifecycle of a domain name". My feeling is "yes". Also, this information is likely to be disclosed anyway; see below.
Data (ii) are required to be published under purposes 1 and 2, as long as there is at least one data element that is required under some purpose and is not available from the registry. (Since the actual registration life cycle is controlled by the registrar and not the registry, this appears likely.) Owing to the way these work, publication of these is likely to "leak" information about (i) or (iii) also.
c. Maximal audience
Given purposes 2 and 3 and probably 5, and since the source of contact information is registrars, the maximal audience is probably everyone on the Internet. If we think that purposes 2, 3, or 5 are limited in respect of who needs to make such contact or who needs to check accuracy, then the maximal audience is the set of all those who have such a need. It's worth observing, however, that at least the technical contact for a name ought to be contactable by anyone on the Internet, since when we want to "facilitate communication with domain contacts" at least part of the reason is as a fallback when a site breaks in some way. (This may suggest that we need to unpack the details of purpose 3.)
3. NAME SERVERS ---------------
a. Collection
Without collecting the name servers, domain names cannot function on the Internet, so this is required under purposes 1 and 2. (Given that the registration of the name itself and the collection of the name servers are both required for the basic functioning of the Internet Domain Name System, it strikes me that we may be missing a more obvious purpose in our list, but I guess (1) and (2) will be enough and we're already so late that I am loathe to suggest something more.)
b. Publication
Whenever a name is available on the Internet, the name server data is already available in the DNS, so this data is necessarily published. Under either purpose 1 or 2 (or both), the data about nameservers in the RDS provides an avenue for troubleshooting issues in the DNS, and so it is required for those purposes.
c. Maximal audience
Anyone who wants to access a site must be able to find this data in the DNS. Potentially anyone who has a problem with resolution can use the data in the RDS to aid in troubleshooting, so the audience under purpose 1 or 2 (or both) is everyone on the Internet.
4. STATUS VALUES ----------------
a. Collection
The status values are not exactly "collected", but are at least in part the result of various actions by the sponsoring registrar and registry on the name. (Some can be set directly.) These govern the disposition of the name in question, and are a necessary condition for having a shared registration system, so they are required under purpose 1.
b. Publication
The status values govern the possible things that could be done to a name, and therefore the data must be published under purpose 1.
c. Maximal audience
At leasr some status values are required for doing some troubleshooting of resolution failures, so the audience for at least some values under purposes 1 or 2 is "everyone on the Internet". It is possible to argue that some of the status values are relevant only to those people who wish to perform some actions on the domain (such as transferring) or people in a position to do some kinds of activity (such as updating contact information). If we really think it necessary, we could undertake the exercise of audience evaluation for each EPP status.
5. DATES ---------
While the dates might appear to be different kinds, they aren't, since for our purposes they all have at least one common utility (see below).
a. Collection
The dates, like status values, are not exactly "collected": they're a consequence of certain activities. They're necessary for the workings of the shared registration systems using the current fee-for-term model that (approximately?) all gTLD registries use today, so they're required under purpose 1.
b. Publication
The dates are required under purpose 1 or 2 in order to aid troubleshooting of resolution. (If a name worked yesterday and not today, it is helpful to know that it was just created -- meaning the old one was deleted -- or that it is expired, or that someone updated the name only last night.)
c. Maximal audience
Because of the troubleshooting aspects of these dates, the audience under purpose 1 or 2 is everyone on the Internet.
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ 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
Going back to the original question from Andrew. This ground is well-covered in the EWG report. In particular, the framework is outlined in principles 25 & 26 of the report:
25: Each data element must be associated with a set of permissible purposes. An initial set of acceptable uses, permissible purposes, and data element needs are identified by this report (see Section III and Annex D). Each permissible purpose must be associated with clearly-defined data element access and use policies. As specified in Section III, an on-going review process must be defined to consider proposed new purposes and periodically update permissible purposes to reflect approved additions, mapping them to existing data elements. A Policy Definition process must be defined to consider proposed new data elements and, when necessary, update defined data elements, mapping them to existing permissible purposes.
26: The list of minimum data elements to be collected, stored and disclosed must be based on known use cases (reflected in this document) and a risk assessment (to be completed prior to RDS implementation).
Annex D of the report then maps all the elements we identified to one or more purposes. We dropped elements that had no legitimate purpose for collection/display. Note that this mapping is in shorthand, so we probably need to expand upon this to satisfy DPA’s. So, this work has largely been done, and I’d suggest we do a review of that work to see if it meets the needs of this group and work on fleshing out elements to purposes in order to satisfy DPA requirements. It would save us a lot of time... Cheers, Rod
+1, Chuck. -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rod Rasmussen Sent: Tuesday, March 28, 2017 12:44 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Going back to the original question from Andrew. This ground is well-covered in the EWG report. In particular, the framework is outlined in principles 25 & 26 of the report:
25: Each data element must be associated with a set of permissible purposes. An initial set of acceptable uses, permissible purposes, and data element needs are identified by this report (see Section III and Annex D). Each permissible purpose must be associated with clearly-defined data element access and use policies. As specified in Section III, an on-going review process must be defined to consider proposed new purposes and periodically update permissible purposes to reflect approved additions, mapping them to existing data elements. A Policy Definition process must be defined to consider proposed new data elements and, when necessary, update defined data elements, mapping them to existing permissible purposes.
26: The list of minimum data elements to be collected, stored and disclosed must be based on known use cases (reflected in this document) and a risk assessment (to be completed prior to RDS implementation).
Annex D of the report then maps all the elements we identified to one or more purposes. We dropped elements that had no legitimate purpose for collection/display. Note that this mapping is in shorthand, so we probably need to expand upon this to satisfy DPA’s. So, this work has largely been done, and I’d suggest we do a review of that work to see if it meets the needs of this group and work on fleshing out elements to purposes in order to satisfy DPA requirements. It would save us a lot of time... Cheers, Rod
Thanks Rod for reminding us of this. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Tuesday, March 28, 2017 12:49 PM To: Rod Rasmussen <rrasmussen@infoblox.com>; gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" +1, Chuck. -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rod Rasmussen Sent: Tuesday, March 28, 2017 12:44 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Going back to the original question from Andrew. This ground is well-covered in the EWG report. In particular, the framework is outlined in principles 25 & 26 of the report:
25: Each data element must be associated with a set of permissible purposes. An initial set of acceptable uses, permissible purposes, and data element needs are identified by this report (see Section III and Annex D). Each permissible purpose must be associated with clearly-defined data element access and use policies. As specified in Section III, an on-going review process must be defined to consider proposed new purposes and periodically update permissible purposes to reflect approved additions, mapping them to existing data elements. A Policy Definition process must be defined to consider proposed new data elements and, when necessary, update defined data elements, mapping them to existing permissible purposes.
26: The list of minimum data elements to be collected, stored and disclosed must be based on known use cases (reflected in this document) and a risk assessment (to be completed prior to RDS implementation).
Annex D of the report then maps all the elements we identified to one or more purposes. We dropped elements that had no legitimate purpose for collection/display. Note that this mapping is in shorthand, so we probably need to expand upon this to satisfy DPA’s. So, this work has largely been done, and I’d suggest we do a review of that work to see if it meets the needs of this group and work on fleshing out elements to purposes in order to satisfy DPA requirements. It would save us a lot of time... Cheers, Rod _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Thanks for the reminder/pointer Rod. Agree that we should leverage the work of the EWG report whenever possible and appropriate. No need to re-invent the wheel. Alex On 3/28/17, 11:43 AM, <gnso-rds-pdp-wg-bounces@icann.org on behalf of rrasmussen@infoblox.com> wrote: Going back to the original question from Andrew. This ground is well-covered in the EWG report. In particular, the framework is outlined in principles 25 & 26 of the report: > 25: Each data element must be associated with a set of permissible purposes. > > An initial set of acceptable uses, permissible purposes, and data element needs are identified by this report (see Section III and Annex D). > > Each permissible purpose must be associated with clearly-defined data element access and use policies. > > As specified in Section III, an on-going review process must be defined to consider proposed new purposes and periodically update permissible purposes to reflect approved additions, mapping them to existing data elements. > > A Policy Definition process must be defined to consider proposed new data elements and, when necessary, update defined data elements, mapping them to existing permissible purposes. > > 26: The list of minimum data elements to be collected, stored and disclosed must be based on known use cases (reflected in this document) and a risk assessment (to be completed prior to RDS implementation). > Annex D of the report then maps all the elements we identified to one or more purposes. We dropped elements that had no legitimate purpose for collection/display. Note that this mapping is in shorthand, so we probably need to expand upon this to satisfy DPA’s. So, this work has largely been done, and I’d suggest we do a review of that work to see if it meets the needs of this group and work on fleshing out elements to purposes in order to satisfy DPA requirements. It would save us a lot of time... Cheers, Rod
+1 @Rod Nathalie On Tuesday, March 28, 2017 1:57 PM, "Deacon, Alex" <Alex_Deacon@mpaa.org> wrote: Thanks for the reminder/pointer Rod. Agree that we should leverage the work of the EWG report whenever possible and appropriate. No need to re-invent the wheel. Alex On 3/28/17, 11:43 AM, <gnso-rds-pdp-wg-bounces@icann.org on behalf of rrasmussen@infoblox.com> wrote: Going back to the original question from Andrew. This ground is well-covered in the EWG report. In particular, the framework is outlined in principles 25 & 26 of the report: > 25: Each data element must be associated with a set of permissible purposes. > > An initial set of acceptable uses, permissible purposes, and data element needs are identified by this report (see Section III and Annex D). > > Each permissible purpose must be associated with clearly-defined data element access and use policies. > > As specified in Section III, an on-going review process must be defined to consider proposed new purposes and periodically update permissible purposes to reflect approved additions, mapping them to existing data elements. > > A Policy Definition process must be defined to consider proposed new data elements and, when necessary, update defined data elements, mapping them to existing permissible purposes. > > 26: The list of minimum data elements to be collected, stored and disclosed must be based on known use cases (reflected in this document) and a risk assessment (to be completed prior to RDS implementation). > Annex D of the report then maps all the elements we identified to one or more purposes. We dropped elements that had no legitimate purpose for collection/display. Note that this mapping is in shorthand, so we probably need to expand upon this to satisfy DPA’s. So, this work has largely been done, and I’d suggest we do a review of that work to see if it meets the needs of this group and work on fleshing out elements to purposes in order to satisfy DPA requirements. It would save us a lot of time... Cheers, Rod _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Agreed, provided it fully accounts for applicable laws. Am 28.03.2017 um 19:57 schrieb Deacon, Alex:
Thanks for the reminder/pointer Rod.
Agree that we should leverage the work of the EWG report whenever possible and appropriate. No need to re-invent the wheel.
Alex
On 3/28/17, 11:43 AM, <gnso-rds-pdp-wg-bounces@icann.org on behalf of rrasmussen@infoblox.com> wrote:
Going back to the original question from Andrew. This ground is well-covered in the EWG report. In particular, the framework is outlined in principles 25 & 26 of the report:
> 25: Each data element must be associated with a set of permissible purposes. > > An initial set of acceptable uses, permissible purposes, and data element needs are identified by this report (see Section III and Annex D). > > Each permissible purpose must be associated with clearly-defined data element access and use policies. > > As specified in Section III, an on-going review process must be defined to consider proposed new purposes and periodically update permissible purposes to reflect approved additions, mapping them to existing data elements. > > A Policy Definition process must be defined to consider proposed new data elements and, when necessary, update defined data elements, mapping them to existing permissible purposes. > > 26: The list of minimum data elements to be collected, stored and disclosed must be based on known use cases (reflected in this document) and a risk assessment (to be completed prior to RDS implementation). >
Annex D of the report then maps all the elements we identified to one or more purposes. We dropped elements that had no legitimate purpose for collection/display. Note that this mapping is in shorthand, so we probably need to expand upon this to satisfy DPA’s.
So, this work has largely been done, and I’d suggest we do a review of that work to see if it meets the needs of this group and work on fleshing out elements to purposes in order to satisfy DPA requirements. It would save us a lot of time...
Cheers,
Rod
_______________________________________________ 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.
The latest regulations being planned were not in place for the EWG so we should not expect them to have accounted for them. It will be our responsibility to take account of applicable laws. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Volker Greimann Sent: Wednesday, March 29, 2017 4:14 AM To: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] a suggestion for "purpose in detail" Agreed, provided it fully accounts for applicable laws. Am 28.03.2017 um 19:57 schrieb Deacon, Alex:
Thanks for the reminder/pointer Rod.
Agree that we should leverage the work of the EWG report whenever possible and appropriate. No need to re-invent the wheel.
Alex
On 3/28/17, 11:43 AM, <gnso-rds-pdp-wg-bounces@icann.org on behalf of rrasmussen@infoblox.com> wrote:
Going back to the original question from Andrew. This ground is well-covered in the EWG report. In particular, the framework is outlined in principles 25 & 26 of the report:
> 25: Each data element must be associated with a set of permissible purposes. > > An initial set of acceptable uses, permissible purposes, and data element needs are identified by this report (see Section III and Annex D). > > Each permissible purpose must be associated with clearly-defined data element access and use policies. > > As specified in Section III, an on-going review process must be defined to consider proposed new purposes and periodically update permissible purposes to reflect approved additions, mapping them to existing data elements. > > A Policy Definition process must be defined to consider proposed new data elements and, when necessary, update defined data elements, mapping them to existing permissible purposes. > > 26: The list of minimum data elements to be collected, stored and disclosed must be based on known use cases (reflected in this document) and a risk assessment (to be completed prior to RDS implementation). >
Annex D of the report then maps all the elements we identified to one or more purposes. We dropped elements that had no legitimate purpose for collection/display. Note that this mapping is in shorthand, so we probably need to expand upon this to satisfy DPA’s.
So, this work has largely been done, and I’d suggest we do a review of that work to see if it meets the needs of this group and work on fleshing out elements to purposes in order to satisfy DPA requirements. It would save us a lot of time...
Cheers,
Rod
_______________________________________________ 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
I have posted a question to today’s Adobe Connect session, just to signal the question, and not to get an answer there. The question is: */Does anyone in the working group have knowledge of octree data management techniques?/* The technique holds promise for how the end product of this rds-pdp working group might be implemented. Octree data management techniques are already used in Internet infrastructures (to reduce collisions etc.). I am doing some tiny work with /non-destructive archaeology/ (think of opening up a tomb or crypt, installing a “Mars Rover” type facility, sealing up the tomb and collecting data remotely). Octree database techniques are increasingly being considered in archaeology as a way of archiving data for wider access and allow levels of gated access. Most archaeologists cannot physically access a site (certainly not all at once) and the approach both protects the integrity of the site, and opens a more level playing field for archaeology research. One additional advantage of using an octree technique, rather than common database management techniques, is that users can further tag data as it relates to their individual uses. Those tags are simply a extension further down the octree tree, where the tags are integral to the subsets of the data assembled by the users, and tied to the work they are engaged in. My impression is that at the Registrar/Registry level this is no more difficult to implement than a relatively flat standard database, but is rich in the range of applications it supports. Sam L.
participants (30)
-
ajs＠anvilwalrusden.com -
allison nixon -
Amr Elsadr -
Andrew Sullivan
-
Ayden Férdeline -
benny＠nordreg.se -
Carlton Samuels -
Chen, Tim -
Chris Pelling -
David Cake -
Deacon, Alex -
Denny Watson -
Gomes, Chuck -
Greg Aaron -
Greg Shatan -
Hollenbeck, Scott -
James Galvin -
John Bambenek -
John Horton -
Lisa Phifer -
Marika Konings -
Metalitz, Steven -
nathalie coupet -
Rob Golding -
Rod Rasmussen -
Sam Lanfranco -
Stephanie Perrin -
theo geurts -
Victoria Sheckler -
Volker Greimann