Apologies, and some reflections on requirements
Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Suffice it to say I agree with all of Andrews points. I also had been feeling uncomfortable with our direction, but had not known the best way in which to bring it up. Thanks Andrew for doing it for me! -J On 25/06/2016, 03:03, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Andrew Sullivan" <gnso-rds-pdp-wg-bounces@icann.org on behalf of ajs@anvilwalrusden.com> wrote:
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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
This is extremely interesting and important information. Could you please explain how registrants and users might access such a distributed database (technically) to modify/correct their data or just to view it? Thank you in advance, Nathalie Sent from my iPhone On Jun 25, 2016, at 6:25 AM, James Gannon <james@cyberinvasion.net> wrote:
Suffice it to say I agree with all of Andrews points. I also had been feeling uncomfortable with our direction, but had not known the best way in which to bring it up. Thanks Andrew for doing it for me!
-J
On 25/06/2016, 03:03, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Andrew Sullivan" <gnso-rds-pdp-wg-bounces@icann.org on behalf of ajs@anvilwalrusden.com> wrote:
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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
On Sat, Jun 25, 2016 at 07:47:12AM -0400, Nathalie Coupet wrote:
Could you please explain how registrants and users might access such a distributed database (technically) to modify/correct their data or just to view it?
This isn't a "might" case: it's a "how do they do it now?" case. I wasn't describing a possible future; I was describing how stuff actually works. Today, if you register a domain name in almost all TLDs (and certainly in any contracted gTLD), you go through a registrar. The registrar has data about whoever registers the name (if you register through a proxy service, in effect they're the registrant, and you have a separate contract with them that permits you continued control over the name they've registered). In particular, all the billing and other contact data is collected by the registrar. To update anything, you go to the registrar, so that's how a registrant updates the data. In "thin" registries, the contact data never leaves the registrar. You can actually see how this works in whois today in com: ---%<---cut here--- ajs$ whois anvilwalrusden.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. 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: ok https://icann.org/epp#ok Updated Date: 09-jun-2016 Creation Date: 30-jun-2010 Expiration Date: 30-jun-2017
Last update of whois database: Sat, 25 Jun 2016 13:20:04 GMT <<<
[now comes a bunch of legal disclaimer] [up to this point, the answer came from Verisign's whois server. Notice the "referral URL". It tells the client, "Query this other URL too."] Domain Name: ANVILWALRUSDEN.COM Domain ID: 1604487787_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.tucows.com Registrar URL: http://tucowsdomains.com Updated Date: 2016-06-09T03:51:47Z Creation Date: 2010-06-30T19:23:14Z Registrar Registration Expiration Date: 2017-06-30T19:23:14Z Sponsoring Registrar: TUCOWS, INC. Sponsoring Registrar IANA ID: 69 Registrar Abuse Contact Email: domainabuse@tucows.com Registrar Abuse Contact Phone: +1.4165350123 Reseller: 2228447 Ontario Inc. Domain Status: ok https://icann.org/epp#ok Registry Registrant ID: Registrant Name: Contact Privacy Inc. Customer 0124230102 Registrant Organization: Contact Privacy Inc. Customer 0124230102 Registrant Street: 96 Mowat Ave Registrant City: Toronto Registrant State/Province: ON Registrant Postal Code: M6K 3M1 Registrant Country: CA Registrant Phone: +1.4165385457 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: anvilwalrusden.com@contactprivacy.com Registry Admin ID: Admin Name: Contact Privacy Inc. Customer 0124230102 Admin Organization: Contact Privacy Inc. Customer 0124230102 Admin Street: 96 Mowat Ave Admin City: Toronto Admin State/Province: ON Admin Postal Code: M6K 3M1 Admin Country: CA Admin Phone: +1.4165385457 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: anvilwalrusden.com@contactprivacy.com Registry Tech ID: Tech Name: Contact Privacy Inc. Customer 0124230102 Tech Organization: Contact Privacy Inc. Customer 0124230102 Tech Street: 96 Mowat Ave Tech City: Toronto Tech State/Province: ON Tech Postal Code: M6K 3M1 Tech Country: CA Tech Phone: +1.4165385457 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: anvilwalrusden.com@contactprivacy.com Name Server: NS1.SYSTEMDNS.COM Name Server: NS2.SYSTEMDNS.COM Name Server: NS3.SYSTEMDNS.COM DNSSEC: unsigned URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
Last update of WHOIS database: 2016-06-09T03:51:47Z <<<
"For more information on Whois status codes, please visit https://icann.org/epp" Registration Service Provider: 2228447 Ontario Inc., ajs@crankycanuck.ca +1.4167311261 This company may be contacted for domain login/passwords, DNS/Nameserver changes, and general domain support questions. This domain's privacy is protected by contactprivacy.com. To reach the domain contacts, please go to http://www.contactprivacy.com and follow the instructions. [and more legal disclaimer] [This part, as you ca see, is from Tucows, where I have a reseller account.] ---cut here--->%--- The problem with whois (the protocol) for this are manifold, and I don't think I need to rehearse them here. But none of that matters, because RDAP has addressed all of those problems, so the technical barriers are no longer in the way. So the answer to your question is that registrars today can look at this data via whois today, and will be able to use RDAP when it is implemented. And if this WG comes up with a sensible privacy policy, then the registrant ought to be able to able to view data that others can't. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. " It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time. "While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model." I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. 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: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. 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
I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements". Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
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: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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 think Andrew is saying two things. 1) Fundamental relationships and business processes have been around for many years and probably can't be blown up. A reality is that the registrant-registrar-registry model exists (and for some good reasons - remember that one of ICANN's missions is to promote competition in the registrar and TLD spaces). 2) Any centralized system introduces additional risks (which SSAC has noted). That goes for a system in which all gTLD registration data would be collected into one centralized super-mega-registry (ARDS), or some centralized point that would be used to regulate access to the various registries. A "decentralized" system could be one in which each registry continues to hold and provide access to data related to the domains in their registries. (With each registry being thick, not thin. A PDP has already decided that.) Andrew, please correct me if I'm wrong. Responding to Chuck's note: I don't see how anything in Andrew's note suggests or requires a charter change. For example, the ARDs is not a requirement that our group must accede to. Federated is an option, synchronized is an option, and siloed registries (with perhaps access requirements) are an option, and there may be others. We figure out technical model after figuring out fundamental questions such as what data should be collected and who should have access to it. Responding to Stephanie's note: yes, the EWG should have been conducted differently. But Fadi created something that circumvented established, transparent community processes, and thus our PDP group is tasked with doing a lot of the same work and having some of the same debates the EWG did. That's simply the situation we are in. A corollary is that nothing the EWG decided is written in stone; it is this PDP WG's prerogative to like or dislike anything the EWG did. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, June 30, 2016 1:59 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements". Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote: Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. " It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time. "While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model." I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. 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
I would like to reiterate that as far as I am concerned our policy work in this pdp is de novo....some things need to be blown up. Since the purpose of the collection use and disclosure has never been decided, and the legal requirements with respect to privacy, data protection, and fundamental rights have only been addressed through the "conflicts with law" workaround which stems from a non-pdp produced policy, expect me to be arguing that if the registrant-registrar-registry model needs to be adjusted, we must do it. Thanks! Stephanie On 2016-06-30 3:40, Greg Aaron wrote:
I think Andrew is saying two things. 1) Fundamental relationships and business processes have been around for many years and probably can’t be blown up. A reality is that the registrant-registrar-registry model exists (and for some good reasons – remember that one of ICANN’s missions is to promote competition in the registrar and TLD spaces). 2) Any centralized system introduces additional risks (which SSAC has noted). That goes for a system in which all gTLD registration data would be collected into one centralized super-mega-registry (ARDS), or some centralized point that would be used to regulate access to the various registries.
A “decentralized” system could be one in which each registry continues to hold and provide access to data related to the domains in their registries. (With each registry being thick, not thin. A PDP has already decided that.)
Andrew, please correct me if I’m wrong.
Responding to Chuck’s note: I don’t see how anything in Andrew’s note suggests or requires a charter change. For example, the ARDs is not a requirement that our group must accede to. Federated is an option, synchronized is an option, and siloed registries (with perhaps access requirements) are an option, and there may be others. We figure out technical model after figuring out fundamental questions such as what data should be collected and who should have access to it.
Responding to Stephanie’s note: yes, the EWG should have been conducted differently. But Fadi created something that circumvented established, transparent community processes, and thus our PDP group is tasked with doing a lot of the same work and having some of the same debates the EWG did. That’s simply the situation we are in. A corollary is that nothing the EWG decided is written in stone; it is this PDP WG’s prerogative to like or dislike anything the EWG did.
All best,
--Greg
**********************************
Greg Aaron
Vice-President, Product Management
iThreat Cyber Group / Cybertoolbelt.com
mobile: +1.215.858.2257
**********************************
The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Stephanie Perrin *Sent:* Thursday, June 30, 2016 1:59 AM *To:* gnso-rds-pdp-wg@icann.org *Subject:* Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry.....
However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach.
In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally).
I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements".
Stephanie Perrin
On 2016-06-29 21:04, Gomes, Chuck wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
Chuck
-----Original Message-----
From:gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan
Sent: Friday, June 24, 2016 10:04 PM
To:gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>
Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers'
understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case.
The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick"
whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data.
Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service.
Whois++ and rwhois attempted to graft on to this basic protocol some
distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?"
In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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>
I totally agree that 'this pdp is de novo' but not if that means doing work over that has already been done. I firmly believe we need to take advantage of work that has already been done understanding that that doesn't mean we have to accept all conclusions from that work without debate or testing. Chuck From: Stephanie Perrin [mailto:stephanie.perrin@mail.utoronto.ca] Sent: Thursday, June 30, 2016 4:06 AM To: Greg Aaron; gnso-rds-pdp-wg@icann.org Cc: Gomes, Chuck Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I would like to reiterate that as far as I am concerned our policy work in this pdp is de novo....some things need to be blown up. Since the purpose of the collection use and disclosure has never been decided, and the legal requirements with respect to privacy, data protection, and fundamental rights have only been addressed through the "conflicts with law" workaround which stems from a non-pdp produced policy, expect me to be arguing that if the registrant-registrar-registry model needs to be adjusted, we must do it. Thanks! Stephanie On 2016-06-30 3:40, Greg Aaron wrote: I think Andrew is saying two things. 1) Fundamental relationships and business processes have been around for many years and probably can't be blown up. A reality is that the registrant-registrar-registry model exists (and for some good reasons - remember that one of ICANN's missions is to promote competition in the registrar and TLD spaces). 2) Any centralized system introduces additional risks (which SSAC has noted). That goes for a system in which all gTLD registration data would be collected into one centralized super-mega-registry (ARDS), or some centralized point that would be used to regulate access to the various registries. A "decentralized" system could be one in which each registry continues to hold and provide access to data related to the domains in their registries. (With each registry being thick, not thin. A PDP has already decided that.) Andrew, please correct me if I'm wrong. Responding to Chuck's note: I don't see how anything in Andrew's note suggests or requires a charter change. For example, the ARDs is not a requirement that our group must accede to. Federated is an option, synchronized is an option, and siloed registries (with perhaps access requirements) are an option, and there may be others. We figure out technical model after figuring out fundamental questions such as what data should be collected and who should have access to it. Responding to Stephanie's note: yes, the EWG should have been conducted differently. But Fadi created something that circumvented established, transparent community processes, and thus our PDP group is tasked with doing a lot of the same work and having some of the same debates the EWG did. That's simply the situation we are in. A corollary is that nothing the EWG decided is written in stone; it is this PDP WG's prerogative to like or dislike anything the EWG did. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, June 30, 2016 1:59 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements". Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote: Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. " It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time. "While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model." I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. 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
It's imperative that we take advantage of the extensive work that the EWG did. Of course it's not the end of conversation, but let's not waste the ridiculous and admirable amount of time and effort that went into the EWG report, including Stephanie's comments about the work (also valuable for our deliberations although I don't necessarily agree). Kiran Malancharuvil Policy Counselor MarkMonitor 415-419-9138 (m) Sent from my mobile, please excuse any typos. On Jun 30, 2016, at 4:35 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: I totally agree that ‘this pdp is de novo’ but not if that means doing work over that has already been done. I firmly believe we need to take advantage of work that has already been done understanding that that doesn’t mean we have to accept all conclusions from that work without debate or testing. Chuck From: Stephanie Perrin [mailto:stephanie.perrin@mail.utoronto.ca] Sent: Thursday, June 30, 2016 4:06 AM To: Greg Aaron; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Cc: Gomes, Chuck Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I would like to reiterate that as far as I am concerned our policy work in this pdp is de novo....some things need to be blown up. Since the purpose of the collection use and disclosure has never been decided, and the legal requirements with respect to privacy, data protection, and fundamental rights have only been addressed through the "conflicts with law" workaround which stems from a non-pdp produced policy, expect me to be arguing that if the registrant-registrar-registry model needs to be adjusted, we must do it. Thanks! Stephanie On 2016-06-30 3:40, Greg Aaron wrote: I think Andrew is saying two things. 1) Fundamental relationships and business processes have been around for many years and probably can’t be blown up. A reality is that the registrant-registrar-registry model exists (and for some good reasons – remember that one of ICANN’s missions is to promote competition in the registrar and TLD spaces). 2) Any centralized system introduces additional risks (which SSAC has noted). That goes for a system in which all gTLD registration data would be collected into one centralized super-mega-registry (ARDS), or some centralized point that would be used to regulate access to the various registries. A “decentralized” system could be one in which each registry continues to hold and provide access to data related to the domains in their registries. (With each registry being thick, not thin. A PDP has already decided that.) Andrew, please correct me if I’m wrong. Responding to Chuck’s note: I don’t see how anything in Andrew’s note suggests or requires a charter change. For example, the ARDs is not a requirement that our group must accede to. Federated is an option, synchronized is an option, and siloed registries (with perhaps access requirements) are an option, and there may be others. We figure out technical model after figuring out fundamental questions such as what data should be collected and who should have access to it. Responding to Stephanie’s note: yes, the EWG should have been conducted differently. But Fadi created something that circumvented established, transparent community processes, and thus our PDP group is tasked with doing a lot of the same work and having some of the same debates the EWG did. That’s simply the situation we are in. A corollary is that nothing the EWG decided is written in stone; it is this PDP WG’s prerogative to like or dislike anything the EWG did. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com<http://cybertoolbelt.com> mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, June 30, 2016 1:59 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements". Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote: Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. " It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time. "While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model." I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. 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
Thanks Kiran and Chuck, and just to clarify I agree...all work needs to be examined and valued. The point I was trying to make below, is one that I believe Andrew had made rather eloquently. Despite a lot of work, we have continued in the trajectory that was set many years ago, both from a technical and policy perspective, despite the growth of the Internet and the expansion of complex policy, competitive, and human rights issues. So if we have built something on a shaky foundation (eg the WHOIS protocol, the RAA) we need to be able to either repair the foundation or get the backhoe out to dig it out and rebuild. Always costs money, but often necessary in construction as in projects such as this. Best Stephanie On 2016-06-30 11:11, Kiran Malancharuvil wrote:
It's imperative that we take advantage of the extensive work that the EWG did. Of course it's not the end of conversation, but let's not waste the ridiculous and admirable amount of time and effort that went into the EWG report, including Stephanie's comments about the work (also valuable for our deliberations although I don't necessarily agree).
Kiran Malancharuvil Policy Counselor MarkMonitor 415-419-9138 (m)
Sent from my mobile, please excuse any typos.
On Jun 30, 2016, at 4:35 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote:
I totally agree that ‘this pdp is de novo’ but not if that means doing work over that has already been done. I firmly believe we need to take advantage of work that has already been done understanding that that doesn’t mean we have to accept all conclusions from that work without debate or testing.
Chuck
From: Stephanie Perrin [mailto:stephanie.perrin@mail.utoronto.ca] Sent: Thursday, June 30, 2016 4:06 AM To: Greg Aaron; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Cc: Gomes, Chuck Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
I would like to reiterate that as far as I am concerned our policy work in this pdp is de novo....some things need to be blown up.
Since the purpose of the collection use and disclosure has never been decided, and the legal requirements with respect to privacy, data protection, and fundamental rights have only been addressed through the "conflicts with law" workaround which stems from a non-pdp produced policy, expect me to be arguing that if the registrant-registrar-registry model needs to be adjusted, we must do it.
Thanks!
Stephanie
On 2016-06-30 3:40, Greg Aaron wrote: I think Andrew is saying two things. 1) Fundamental relationships and business processes have been around for many years and probably can’t be blown up. A reality is that the registrant-registrar-registry model exists (and for some good reasons – remember that one of ICANN’s missions is to promote competition in the registrar and TLD spaces). 2) Any centralized system introduces additional risks (which SSAC has noted). That goes for a system in which all gTLD registration data would be collected into one centralized super-mega-registry (ARDS), or some centralized point that would be used to regulate access to the various registries. A “decentralized” system could be one in which each registry continues to hold and provide access to data related to the domains in their registries. (With each registry being thick, not thin. A PDP has already decided that.) Andrew, please correct me if I’m wrong.
Responding to Chuck’s note: I don’t see how anything in Andrew’s note suggests or requires a charter change. For example, the ARDs is not a requirement that our group must accede to. Federated is an option, synchronized is an option, and siloed registries (with perhaps access requirements) are an option, and there may be others. We figure out technical model after figuring out fundamental questions such as what data should be collected and who should have access to it.
Responding to Stephanie’s note: yes, the EWG should have been conducted differently. But Fadi created something that circumvented established, transparent community processes, and thus our PDP group is tasked with doing a lot of the same work and having some of the same debates the EWG did. That’s simply the situation we are in. A corollary is that nothing the EWG decided is written in stone; it is this PDP WG’s prerogative to like or dislike anything the EWG did.
All best, --Greg
********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com<http://cybertoolbelt.com> mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, June 30, 2016 1:59 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry.....
However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach.
In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally).
I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements".
Stephanie Perrin
On 2016-06-29 21:04, Gomes, Chuck wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
Chuck
-----Original Message-----
From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan
Sent: Friday, June 24, 2016 10:04 PM
To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>
Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers'
understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case.
The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick"
whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data.
Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service.
Whois++ and rwhois attempted to graft on to this basic protocol some
distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?"
In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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
Thanks Stephanie. I have no disagreement with your point but want to say that I do not think that we have any obligation to build our work on the foundation of the Whois protocol or the RAA. Chuck From: Stephanie Perrin [mailto:stephanie.perrin@mail.utoronto.ca] Sent: Thursday, June 30, 2016 11:27 AM To: Kiran Malancharuvil; Gomes, Chuck Cc: Greg Aaron; gnso-rds-pdp-wg@icann.org; Fabricio Vayra Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Thanks Kiran and Chuck, and just to clarify I agree...all work needs to be examined and valued. The point I was trying to make below, is one that I believe Andrew had made rather eloquently. Despite a lot of work, we have continued in the trajectory that was set many years ago, both from a technical and policy perspective, despite the growth of the Internet and the expansion of complex policy, competitive, and human rights issues. So if we have built something on a shaky foundation (eg the WHOIS protocol, the RAA) we need to be able to either repair the foundation or get the backhoe out to dig it out and rebuild. Always costs money, but often necessary in construction as in projects such as this. Best Stephanie On 2016-06-30 11:11, Kiran Malancharuvil wrote: It's imperative that we take advantage of the extensive work that the EWG did. Of course it's not the end of conversation, but let's not waste the ridiculous and admirable amount of time and effort that went into the EWG report, including Stephanie's comments about the work (also valuable for our deliberations although I don't necessarily agree). Kiran Malancharuvil Policy Counselor MarkMonitor 415-419-9138 (m) Sent from my mobile, please excuse any typos. On Jun 30, 2016, at 4:35 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com><mailto:cgomes@verisign.com><mailto:cgomes@verisign.com>> wrote: I totally agree that 'this pdp is de novo' but not if that means doing work over that has already been done. I firmly believe we need to take advantage of work that has already been done understanding that that doesn't mean we have to accept all conclusions from that work without debate or testing. Chuck From: Stephanie Perrin [mailto:stephanie.perrin@mail.utoronto.ca] Sent: Thursday, June 30, 2016 4:06 AM To: Greg Aaron; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org> Cc: Gomes, Chuck Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I would like to reiterate that as far as I am concerned our policy work in this pdp is de novo....some things need to be blown up. Since the purpose of the collection use and disclosure has never been decided, and the legal requirements with respect to privacy, data protection, and fundamental rights have only been addressed through the "conflicts with law" workaround which stems from a non-pdp produced policy, expect me to be arguing that if the registrant-registrar-registry model needs to be adjusted, we must do it. Thanks! Stephanie On 2016-06-30 3:40, Greg Aaron wrote: I think Andrew is saying two things. 1) Fundamental relationships and business processes have been around for many years and probably can't be blown up. A reality is that the registrant-registrar-registry model exists (and for some good reasons - remember that one of ICANN's missions is to promote competition in the registrar and TLD spaces). 2) Any centralized system introduces additional risks (which SSAC has noted). That goes for a system in which all gTLD registration data would be collected into one centralized super-mega-registry (ARDS), or some centralized point that would be used to regulate access to the various registries. A "decentralized" system could be one in which each registry continues to hold and provide access to data related to the domains in their registries. (With each registry being thick, not thin. A PDP has already decided that.) Andrew, please correct me if I'm wrong. Responding to Chuck's note: I don't see how anything in Andrew's note suggests or requires a charter change. For example, the ARDs is not a requirement that our group must accede to. Federated is an option, synchronized is an option, and siloed registries (with perhaps access requirements) are an option, and there may be others. We figure out technical model after figuring out fundamental questions such as what data should be collected and who should have access to it. Responding to Stephanie's note: yes, the EWG should have been conducted differently. But Fadi created something that circumvented established, transparent community processes, and thus our PDP group is tasked with doing a lot of the same work and having some of the same debates the EWG did. That's simply the situation we are in. A corollary is that nothing the EWG decided is written in stone; it is this PDP WG's prerogative to like or dislike anything the EWG did. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com<http://cybertoolbelt.com><http://cybertoolbelt.com> mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. 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> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, June 30, 2016 1:59 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements". Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote: Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. " It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time. "While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model." I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. Chuck -----Original Message----- 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> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com><mailto: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><mailto: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><mailto: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><mailto:gnso-rds-pdp-wg@icann.org><mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Getting back to the basics ... On the question of "what data should be collected" (lets leave who by for a moment) can we get to some agreement about what data is actually needed for a domain to exist (be that collected, generated or created) and what additional data is needed for it to be used I _think_ this is just: Required domain-name registrar expiry date auth-code status And for it to be of some "functional" use: Optional nameservers Rob
We will get there Rob. Not there yet. Chuck -----Original Message----- From: Rob Golding [mailto:rob.golding@astutium.com] Sent: Monday, July 04, 2016 8:46 PM To: Stephanie Perrin Cc: Kiran Malancharuvil; Gomes, Chuck; gnso-rds-pdp-wg@icann.org Subject: Starting from Scratch Getting back to the basics ... On the question of "what data should be collected" (lets leave who by for a moment) can we get to some agreement about what data is actually needed for a domain to exist (be that collected, generated or created) and what additional data is needed for it to be used I _think_ this is just: Required domain-name registrar expiry date auth-code status And for it to be of some "functional" use: Optional nameservers Rob
Rob, At 2016-07-05 01:46:30 +0100 Rob Golding <rob.golding@astutium.com> wrote:
Getting back to the basics ...
On the question of "what data should be collected" (lets leave who by for a moment) can we get to some agreement about what data is actually needed for a domain to exist (be that collected, generated or created) and what additional data is needed for it to be used
Interesting thought experiment, although I'm not sure how far it will go. Lets see. :)
I _think_ this is just: Required domain-name
Yes.
registrar
Only in TLD that have a registry/registrar model. (And we are only concerned about gTLD in this WG, right?)
expiry date
Yes. Possibly.
auth-code
For gTLD which support transferring ownership via this code, then yes. Definitely not true for gTLD that do not have a registry/registrar model, and possibly not true for some other gTLD as well. Also note that this is not baked into DNS technology or anything like that, but is only an artifact of a current registrar transfer system. Fundamentally this is a way to authenticate the registrant, which is what the registry really needs.
status
What does this mean?
And for it to be of some "functional" use: Optional nameservers
And also optionally: DS record (or DNSKEY or other cryptographic information which can be used to produce a DS record for DNSSEC). So putting together, for gTLD without registrars, the registry needs to know: domain-name expiry date nameservers [optional] ds [optional] For gTLD with a registry/registrar model, the registry needs to know: domain-name expiry date nameservers [optional] ds [optional] registrar registrant authentication As a final note, if there are no registrars then everything except for the expiry date can be obtained from the DNS itself. If there are registrars then the registrar and the registrant authentication also sit outside the DNS. Cheers, -- Shane
We are getting ahead of our work plan. As much as I also am tempted to join the discussion myself, I will refrain until we start deliberating on data elements. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Shane Kerr Sent: Tuesday, July 05, 2016 11:15 AM To: Rob Golding Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Starting from Scratch Rob, At 2016-07-05 01:46:30 +0100 Rob Golding <rob.golding@astutium.com> wrote:
Getting back to the basics ...
On the question of "what data should be collected" (lets leave who by for a moment) can we get to some agreement about what data is actually needed for a domain to exist (be that collected, generated or created) and what additional data is needed for it to be used
Interesting thought experiment, although I'm not sure how far it will go. Lets see. :)
I _think_ this is just: Required domain-name
Yes.
registrar
Only in TLD that have a registry/registrar model. (And we are only concerned about gTLD in this WG, right?)
expiry date
Yes. Possibly.
auth-code
For gTLD which support transferring ownership via this code, then yes. Definitely not true for gTLD that do not have a registry/registrar model, and possibly not true for some other gTLD as well. Also note that this is not baked into DNS technology or anything like that, but is only an artifact of a current registrar transfer system. Fundamentally this is a way to authenticate the registrant, which is what the registry really needs.
status
What does this mean?
And for it to be of some "functional" use: Optional nameservers
And also optionally: DS record (or DNSKEY or other cryptographic information which can be used to produce a DS record for DNSSEC). So putting together, for gTLD without registrars, the registry needs to know: domain-name expiry date nameservers [optional] ds [optional] For gTLD with a registry/registrar model, the registry needs to know: domain-name expiry date nameservers [optional] ds [optional] registrar registrant authentication As a final note, if there are no registrars then everything except for the expiry date can be obtained from the DNS itself. If there are registrars then the registrar and the registrant authentication also sit outside the DNS. Cheers, -- Shane
registrar Only in TLD that have a registry/registrar model. (And we are only concerned about gTLD in this WG, right?)
Yes, as a WG we're essentially only concerned with gTLDs under ICANNs remit, so they all have a Registry/Registrar model (even if the Registrar on a brand-tld could be the Registry)
auth-code Also note that this is not baked into DNS technology or anything like that, but is only an artifact of a current registrar transfer system. Fundamentally this is a way to authenticate the registrant, which is what the registry really needs.
It's less about authentication of the Registrant, and more about ensuring authorisation has been gained for the Transfer.
status What does this mean?
Domains are (currently) required to have "status" code(s) relating to locks, udrp etc - but on further reflection it's not absolutely necessary for the domain name to exist or function (although will be there "internally" at the Registry)
And for it to be of some "functional" use: Optional nameservers
And also optionally: DS record (or DNSKEY or other cryptographic information which can be used to produce a DS record for DNSSEC).
Is the most-effective Denial-Of-Service methodology for domains actually needed for it to "work" though (leaving aside how many dont work because of dnssec) ? Probably. So ... To Exist = * domain-name (what it is) * registrar (who manages it) To Function [optional] = * nameservers * ds-stuff To Manage / Needed for Internal Systems = * transfer authentication [optional dependant on registration model] * expiry date * status
As a final note, if there are no registrars then everything except for the expiry date can be obtained from the DNS itself.
In principle I agree - I'm sure we can argue the minutiae of detail about whether it needs to be somewhere else for DNS to work though Anyone else have items to add which are _required_ rather than one-or-more of wants/nice-to-have/needed-for-my-business-model etc ? Rob
I am afraid we are going in too much detail...too EARLY for that ! Best Regards Best Regards --ff-- Mail sent from my mobile phone. Excuse for brievety. Le 5 juil. 2016 16:49, "Rob Golding" <rob.golding@astutium.com> a écrit :
registrar
Only in TLD that have a registry/registrar model. (And we are only concerned about gTLD in this WG, right?)
Yes, as a WG we're essentially only concerned with gTLDs under ICANNs remit, so they all have a Registry/Registrar model (even if the Registrar on a brand-tld could be the Registry)
auth-code
Also note that this is not baked into DNS technology or anything like that, but is only an artifact of a current registrar transfer system. Fundamentally this is a way to authenticate the registrant, which is what the registry really needs.
It's less about authentication of the Registrant, and more about ensuring authorisation has been gained for the Transfer.
status
What does this mean?
Domains are (currently) required to have "status" code(s) relating to locks, udrp etc - but on further reflection it's not absolutely necessary for the domain name to exist or function (although will be there "internally" at the Registry)
And for it to be of some "functional" use:
Optional nameservers
And also optionally: DS record (or DNSKEY or other cryptographic information which can be used to produce a DS record for DNSSEC).
Is the most-effective Denial-Of-Service methodology for domains actually needed for it to "work" though (leaving aside how many dont work because of dnssec) ? Probably.
So ...
To Exist = * domain-name (what it is) * registrar (who manages it)
To Function [optional] = * nameservers * ds-stuff
To Manage / Needed for Internal Systems = * transfer authentication [optional dependant on registration model] * expiry date * status
As a final note, if there are no registrars then everything except for
the expiry date can be obtained from the DNS itself.
In principle I agree - I'm sure we can argue the minutiae of detail about whether it needs to be somewhere else for DNS to work though
Anyone else have items to add which are _required_ rather than one-or-more of wants/nice-to-have/needed-for-my-business-model etc ?
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Dear All, It looks as though we have started the deliberation and getting in deep waters. Are we going according to the workplan? ᐧ Regards Nanghaka Daniel K. Executive Director - ILICIT Africa / Council Member - FOSSFA / Community Lead - ISOC Uganda Chapter Mobile +256 772 898298 (Uganda) Skype: daniel.nanghaka ----------------------------------------- *"Working for Africa" * ----------------------------------------- On Tue, Jul 5, 2016 at 6:51 PM, Farell Folly <farellfolly@gmail.com> wrote:
I am afraid we are going in too much detail...too EARLY for that !
Best Regards
Best Regards --ff--
Mail sent from my mobile phone. Excuse for brievety. Le 5 juil. 2016 16:49, "Rob Golding" <rob.golding@astutium.com> a écrit :
registrar
Only in TLD that have a registry/registrar model. (And we are only concerned about gTLD in this WG, right?)
Yes, as a WG we're essentially only concerned with gTLDs under ICANNs remit, so they all have a Registry/Registrar model (even if the Registrar on a brand-tld could be the Registry)
auth-code
Also note that this is not baked into DNS technology or anything like that, but is only an artifact of a current registrar transfer system. Fundamentally this is a way to authenticate the registrant, which is what the registry really needs.
It's less about authentication of the Registrant, and more about ensuring authorisation has been gained for the Transfer.
status
What does this mean?
Domains are (currently) required to have "status" code(s) relating to locks, udrp etc - but on further reflection it's not absolutely necessary for the domain name to exist or function (although will be there "internally" at the Registry)
And for it to be of some "functional" use:
Optional nameservers
And also optionally: DS record (or DNSKEY or other cryptographic information which can be used to produce a DS record for DNSSEC).
Is the most-effective Denial-Of-Service methodology for domains actually needed for it to "work" though (leaving aside how many dont work because of dnssec) ? Probably.
So ...
To Exist = * domain-name (what it is) * registrar (who manages it)
To Function [optional] = * nameservers * ds-stuff
To Manage / Needed for Internal Systems = * transfer authentication [optional dependant on registration model] * expiry date * status
As a final note, if there are no registrars then everything except for
the expiry date can be obtained from the DNS itself.
In principle I agree - I'm sure we can argue the minutiae of detail about whether it needs to be somewhere else for DNS to work though
Anyone else have items to add which are _required_ rather than one-or-more of wants/nice-to-have/needed-for-my-business-model etc ?
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
Simple answer: no. We are getting ahead of the work plan as I have tried to say in several other messages. The dialog is good but not timely. If we allow this to happen we will lose a lot time because we will have to repeat all later and we will find ourselves jumping all over the place instead of focusing on where we need to focus at the time. So I strongly request everyone to refrain. Chuck Sent from my iPhone On Jul 5, 2016, at 11:58 AM, DANIEL NANGHAKA <dndannang@gmail.com<mailto:dndannang@gmail.com>> wrote: Dear All, It looks as though we have started the deliberation and getting in deep waters. Are we going according to the workplan? [https://mailfoogae.appspot.com/t?sender=aZG5kYW5uYW5nQGdtYWlsLmNvbQ%3D%3D&type=zerocontent&guid=4b6d779d-e7cf-4bb1-814e-5c6ea71d6524]ᐧ Regards Nanghaka Daniel K. Executive Director - ILICIT Africa / Council Member - FOSSFA / Community Lead - ISOC Uganda Chapter Mobile +256 772 898298 (Uganda) Skype: daniel.nanghaka ----------------------------------------- "Working for Africa" ----------------------------------------- [https://docs.google.com/uc?export=download&id=0BwH7MatcY6gPOGxHaDhJMGZwN2c&r...] [https://docs.google.com/uc?export=download&id=0BwH7MatcY6gPeFAxdFF3Skk4b3M&r...] [https://docs.google.com/uc?export=download&id=0BwH7MatcY6gPSF9OWXFHYkV3ZVk&r...] On Tue, Jul 5, 2016 at 6:51 PM, Farell Folly <farellfolly@gmail.com<mailto:farellfolly@gmail.com>> wrote: I am afraid we are going in too much detail...too EARLY for that ! Best Regards Best Regards --ff-- Mail sent from my mobile phone. Excuse for brievety. Le 5 juil. 2016 16:49, "Rob Golding" <rob.golding@astutium.com<mailto:rob.golding@astutium.com>> a écrit : registrar Only in TLD that have a registry/registrar model. (And we are only concerned about gTLD in this WG, right?) Yes, as a WG we're essentially only concerned with gTLDs under ICANNs remit, so they all have a Registry/Registrar model (even if the Registrar on a brand-tld could be the Registry) auth-code Also note that this is not baked into DNS technology or anything like that, but is only an artifact of a current registrar transfer system. Fundamentally this is a way to authenticate the registrant, which is what the registry really needs. It's less about authentication of the Registrant, and more about ensuring authorisation has been gained for the Transfer. status What does this mean? Domains are (currently) required to have "status" code(s) relating to locks, udrp etc - but on further reflection it's not absolutely necessary for the domain name to exist or function (although will be there "internally" at the Registry) And for it to be of some "functional" use: Optional nameservers And also optionally: DS record (or DNSKEY or other cryptographic information which can be used to produce a DS record for DNSSEC). Is the most-effective Denial-Of-Service methodology for domains actually needed for it to "work" though (leaving aside how many dont work because of dnssec) ? Probably. So ... To Exist = * domain-name (what it is) * registrar (who manages it) To Function [optional] = * nameservers * ds-stuff To Manage / Needed for Internal Systems = * transfer authentication [optional dependant on registration model] * expiry date * status As a final note, if there are no registrars then everything except for the expiry date can be obtained from the DNS itself. In principle I agree - I'm sure we can argue the minutiae of detail about whether it needs to be somewhere else for DNS to work though Anyone else have items to add which are _required_ rather than one-or-more of wants/nice-to-have/needed-for-my-business-model etc ? 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
Rob You don’t need the auth-code – you generally generate that on the registrar or registry side, so it’s not actually being collected You *might* need the “create date” Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 On 05/07/2016, 01:46, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Rob Golding" <gnso-rds-pdp-wg-bounces@icann.org on behalf of rob.golding@astutium.com> wrote: Getting back to the basics ... On the question of "what data should be collected" (lets leave who by for a moment) can we get to some agreement about what data is actually needed for a domain to exist (be that collected, generated or created) and what additional data is needed for it to be used I _think_ this is just: Required domain-name registrar expiry date auth-code status And for it to be of some "functional" use: Optional nameservers Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I am afraid we are going in too much detail...too soon.! Best Regards --ff-- Mail sent from my mobile phone. Excuse for brievety. Le 5 juil. 2016 16:25, "Michele Neylon - Blacknight" <michele@blacknight.com> a écrit :
Rob
You don’t need the auth-code – you generally generate that on the registrar or registry side, so it’s not actually being collected You *might* need the “create date”
Regards
Michele
-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
On 05/07/2016, 01:46, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Rob Golding" <gnso-rds-pdp-wg-bounces@icann.org on behalf of rob.golding@astutium.com> wrote:
Getting back to the basics ...
On the question of "what data should be collected" (lets leave who by for a moment) can we get to some agreement about what data is actually needed for a domain to exist (be that collected, generated or created) and what additional data is needed for it to be used
I _think_ this is just: Required domain-name registrar expiry date auth-code status
And for it to be of some "functional" use: Optional nameservers
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I am afraid we are going in too much detail...too soon.!
With all the other discussions on Costs SMTP Auth Multi-level-access and so on, I just thought it might be worth us having the (short) list about what is *actually needed* to help "frame" things Afterall everything else is simply a combination of other-peoples-wishlists :) Rob
+1 Stephanie Perrin On 2016-07-05 11:53, Rob Golding wrote:
I am afraid we are going in too much detail...too soon.!
With all the other discussions on Costs SMTP Auth Multi-level-access and so on, I just thought it might be worth us having the (short) list about what is *actually needed* to help "frame" things
Afterall everything else is simply a combination of other-peoples-wishlists :)
Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Michele Neylon - Blacknight wrote:
You don’t need the auth-code – you generally generate that on the registrar or registry side, so it’s not actually being collected
I agree, I did put
(be that collected, generated or created) to try and cover that :)
You *might* need the “create date”
What's the functional or registration requirement for create-date ? Rob
I agree with Chuck. We should be starting from a fresh slate, but this does not mean we cannot consider the work that others have already done. We do not necessarily need to accept all of their findings but it would seem prudent to at least review their work. If there are any obvious gaps (and a cursory glance at past Policy Development Processes suggests to me we need to give much more consideration to shielding personally identifiable information), I hope we can re-allocate our resources to filling in the blanks rather than devoting them to re-inventing the wheel. And for what it is worth, I too am supportive of a charter change, just so long as it is not seen as a tool by some to continue reaping the benefits of an open-access WHOIS through inertia. If there is a genuine need to change the charter, let's do it. - Ayden On Thu, Jun 30, 2016 2:33 PM, Gomes, Chuck cgomes@verisign.com wrote: I totally agree that ‘this pdp is de novo’ but not if that means doing work over that has already been done. I firmly believe we need to take advantage of work that has already been done understanding that that doesn’t mean we have to accept all conclusions from that work without debate or testing. Chuck From: Stephanie Perrin [mailto:stephanie.perrin@mail.utoronto.ca] Sent: Thursday, June 30, 2016 4:06 AM To: Greg Aaron; gnso-rds-pdp-wg@icann.org Cc: Gomes, Chuck Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I would like to reiterate that as far as I am concerned our policy work in this pdp is de novo....some things need to be blown up. Since the purpose of the collection use and disclosure has never been decided, and the legal requirements with respect to privacy, data protection, and fundamental rights have only been addressed through the “conflicts with law” workaround which stems from a non-pdp produced policy, expect me to be arguing that if the registrant-registrar-registry model needs to be adjusted, we must do it. Thanks! Stephanie On 2016-06-30 3:40, Greg Aaron wrote: I think Andrew is saying two things. 1) Fundamental relationships and business processes have been around for many years and probably can’t be blown up. A reality is that the registrant-registrar-registry model exists (and for some good reasons – remember that one of ICANN’s missions is to promote competition in the registrar and TLD spaces). 2) Any centralized system introduces additional risks (which SSAC has noted). That goes for a system in which all gTLD registration data would be collected into one centralized super-mega-registry (ARDS), or some centralized point that would be used to regulate access to the various registries. A “decentralized” system could be one in which each registry continues to hold and provide access to data related to the domains in their registries. (With each registry being thick, not thin. A PDP has already decided that.) Andrew, please correct me if I’m wrong. Responding to Chuck’s note: I don’t see how anything in Andrew’s note suggests or requires a charter change. For example, the ARDs is not a requirement that our group must accede to. Federated is an option, synchronized is an option, and siloed registries (with perhaps access requirements) are an option, and there may be others. We figure out technical model after figuring out fundamental questions such as what data should be collected and who should have access to it. Responding to Stephanie’s note: yes, the EWG should have been conducted differently. But Fadi created something that circumvented established, transparent community processes, and thus our PDP group is tasked with doing a lot of the same work and having some of the same debates the EWG did. That’s simply the situation we are in. A corollary is that nothing the EWG decided is written in stone; it is this PDP WG’s prerogative to like or dislike anything the EWG did. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. From: gnso-rds-pdp-wg-bounces@icann.org [ mailto:gnso-rds-pdp-wg-bounces@icann.org ] On Behalf Of Stephanie Perrin Sent: Thursday, June 30, 2016 1:59 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to “figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build” (loosely translated). “What to build” is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about “video surveillance” to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of “requirements”. Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote: Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. “ It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a “thick” storage model where queries are served from synchronized data, the runner-up FRDS actually uses “thin” registries, querying data from registrars and validators in real-time. “While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model.” I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. 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: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, “I need to leave on $date,” entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build “requirements” that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called “thin” registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to “fix up” whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, “thick whois” gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created “thick” whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing “the same data” in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a “distributed database”, where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, “What data should be collected?” In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. 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 Ayden Férdeline Statement of Interest
I would be happy to be wrong about the need for a charter change so we will explore that further. If the main thing we are talking about is Federated v. Distributed, then I don't think a charter change would be needed. Am I correct that is the main issue or is there more to what Andrew is suggesting? Andrew? Chuck Sent from my iPhone On Jun 30, 2016, at 3:40 AM, Greg Aaron <gca@icginc.com<mailto:gca@icginc.com>> wrote: I think Andrew is saying two things. 1) Fundamental relationships and business processes have been around for many years and probably can’t be blown up. A reality is that the registrant-registrar-registry model exists (and for some good reasons – remember that one of ICANN’s missions is to promote competition in the registrar and TLD spaces). 2) Any centralized system introduces additional risks (which SSAC has noted). That goes for a system in which all gTLD registration data would be collected into one centralized super-mega-registry (ARDS), or some centralized point that would be used to regulate access to the various registries. A “decentralized” system could be one in which each registry continues to hold and provide access to data related to the domains in their registries. (With each registry being thick, not thin. A PDP has already decided that.) Andrew, please correct me if I’m wrong. Responding to Chuck’s note: I don’t see how anything in Andrew’s note suggests or requires a charter change. For example, the ARDs is not a requirement that our group must accede to. Federated is an option, synchronized is an option, and siloed registries (with perhaps access requirements) are an option, and there may be others. We figure out technical model after figuring out fundamental questions such as what data should be collected and who should have access to it. Responding to Stephanie’s note: yes, the EWG should have been conducted differently. But Fadi created something that circumvented established, transparent community processes, and thus our PDP group is tasked with doing a lot of the same work and having some of the same debates the EWG did. That’s simply the situation we are in. A corollary is that nothing the EWG decided is written in stone; it is this PDP WG’s prerogative to like or dislike anything the EWG did. All best, --Greg ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / http://Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Thursday, June 30, 2016 1:59 AM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements". Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote: Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. " It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time. "While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model." I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. 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
On Thu, Jun 30, 2016 at 08:20:50AM +0000, Gomes, Chuck wrote:
I would be happy to be wrong about the need for a charter change so we will explore that further. If the main thing we are talking about is Federated v. Distributed, then I don't think a charter change would be needed. Am I correct that is the main issue or is there more to what Andrew is suggesting?
Well, there may be more or less. If you look at the model diagrams I sent, you'll notice that they all include the registration side of this as well. Some of our conversations have been framed as though there is some _other_ place where the registration data gets collected, but there isn't. It's all collected through registrars and registries. This is part of why I was trying to suggest that, "What data is collected?" is not one question, but many. Only in Model I -- which hasn't existed for years -- do we have a system in which you can meaningfully ask, "What is collected?" without also asking, "Who collects it?" In Model II, registrars (and only registrars) collect all the data that comes from a registrant. They pass _some_ data along to the registries. In Model IV, the same approach can be used. In Model III, registrars collect all the data, but they also pass almost all of it along to registries. So, three parties (including the registrant) have the data, and one of those parties (the registry) has no direct agreement with the originator of the data. Model IV can also use this approach. Model IV has the additional property that, depending on the authentication of who asks the question, the protocol can provide more or less data in the response. It can do this regardless of who collected the data. Therefore, the issue here is really two dimensional: which parties have any given set of data at any time, and how much of that data will it disclose. As Jay Daley said in the meeting the other day, the second of those dimensions can be answered in steps: "assume completely unauthenticated access; how much is revealed?", and so on. The answer to those issues is _unrelated_ to the first dimension if you pick the right protocol to start with, because you can specify from the beginning that any protocol that could possibly meet our needs must work in a distributed fashion. In that case, you're sort of stuck with RDAP, or with inventing one yourself, because our experience with whois (the protocol, port 43 and webby things built atop it) is that it doesn't work that reliably. Does this answer your question? A -- Andrew Sullivan ajs@anvilwalrusden.com
I've only spent today really looking at RDAP in detail, but to me it looks like it is lightweight and accomplishes everything we need including the ability to generate new schema as required to extend to new data fields and provide flexibility when determining which authenticated users get to see which data. Apologies in advance if I am being naïve. /marksv -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 8:57 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements On Thu, Jun 30, 2016 at 08:20:50AM +0000, Gomes, Chuck wrote:
I would be happy to be wrong about the need for a charter change so we will explore that further. If the main thing we are talking about is Federated v. Distributed, then I don't think a charter change would be needed. Am I correct that is the main issue or is there more to what Andrew is suggesting?
Well, there may be more or less. If you look at the model diagrams I sent, you'll notice that they all include the registration side of this as well. Some of our conversations have been framed as though there is some _other_ place where the registration data gets collected, but there isn't. It's all collected through registrars and registries. This is part of why I was trying to suggest that, "What data is collected?" is not one question, but many. Only in Model I -- which hasn't existed for years -- do we have a system in which you can meaningfully ask, "What is collected?" without also asking, "Who collects it?" In Model II, registrars (and only registrars) collect all the data that comes from a registrant. They pass _some_ data along to the registries. In Model IV, the same approach can be used. In Model III, registrars collect all the data, but they also pass almost all of it along to registries. So, three parties (including the registrant) have the data, and one of those parties (the registry) has no direct agreement with the originator of the data. Model IV can also use this approach. Model IV has the additional property that, depending on the authentication of who asks the question, the protocol can provide more or less data in the response. It can do this regardless of who collected the data. Therefore, the issue here is really two dimensional: which parties have any given set of data at any time, and how much of that data will it disclose. As Jay Daley said in the meeting the other day, the second of those dimensions can be answered in steps: "assume completely unauthenticated access; how much is revealed?", and so on. The answer to those issues is _unrelated_ to the first dimension if you pick the right protocol to start with, because you can specify from the beginning that any protocol that could possibly meet our needs must work in a distributed fashion. In that case, you're sort of stuck with RDAP, or with inventing one yourself, because our experience with whois (the protocol, port 43 and webby things built atop it) is that it doesn't work that reliably. Does this answer your question? A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or...
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored. -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 8:57 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements On Thu, Jun 30, 2016 at 08:20:50AM +0000, Gomes, Chuck wrote:
I would be happy to be wrong about the need for a charter change so we will explore that further. If the main thing we are talking about is Federated v. Distributed, then I don't think a charter change would be needed. Am I correct that is the main issue or is there more to what Andrew is suggesting?
Well, there may be more or less. If you look at the model diagrams I sent, you'll notice that they all include the registration side of this as well. Some of our conversations have been framed as though there is some _other_ place where the registration data gets collected, but there isn't. It's all collected through registrars and registries. This is part of why I was trying to suggest that, "What data is collected?" is not one question, but many. Only in Model I -- which hasn't existed for years -- do we have a system in which you can meaningfully ask, "What is collected?" without also asking, "Who collects it?" In Model II, registrars (and only registrars) collect all the data that comes from a registrant. They pass _some_ data along to the registries. In Model IV, the same approach can be used. In Model III, registrars collect all the data, but they also pass almost all of it along to registries. So, three parties (including the registrant) have the data, and one of those parties (the registry) has no direct agreement with the originator of the data. Model IV can also use this approach. Model IV has the additional property that, depending on the authentication of who asks the question, the protocol can provide more or less data in the response. It can do this regardless of who collected the data. Therefore, the issue here is really two dimensional: which parties have any given set of data at any time, and how much of that data will it disclose. As Jay Daley said in the meeting the other day, the second of those dimensions can be answered in steps: "assume completely unauthenticated access; how much is revealed?", and so on. The answer to those issues is _unrelated_ to the first dimension if you pick the right protocol to start with, because you can specify from the beginning that any protocol that could possibly meet our needs must work in a distributed fashion. In that case, you're sort of stuck with RDAP, or with inventing one yourself, because our experience with whois (the protocol, port 43 and webby things built atop it) is that it doesn't work that reliably. Does this answer your question? A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or...
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is. I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear. (Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
I think it's perfectly reasonable to expect accurate WhoIs data, proxy services included, so long as contracts are enforced. That isn't the case today as far as I can tell, but with ICANN under new management I think we should hold ICANN, registries, registrars AND proxy providers accountable to provide good data with penalties consistently enforced. -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 11:07 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is. I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear. (Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or...
I disagree. The only party that should be responsible for maintaining good data is the registrant. The responsibilities of registrars, registries and proxy services should revolve only on the correct maintenance of that data and on acting when informed about actual issues with the whois data. Best, Volker Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy services included, so long as contracts are enforced. That isn't the case today as far as I can tell, but with ICANN under new management I think we should hold ICANN, registries, registrars AND proxy providers accountable to provide good data with penalties consistently enforced.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 11:07 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.)
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or... _______________________________________________ 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 Responsibility is of the party who is driving profit or providing service. The Registrant is the party who is to be checked for his / her credentials to prevent misuse. The situation is alarming- this is evident of the data being published y various Registries or Governments from time to time related to Bogus Registrations, Misused Domain names cancelled or and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton / Sentinel / MXBlackList / Avast etc such Engines can be referred to for such data collection for the use of consultations. And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. To begin with, the phone is the Personal verified connection by the local authorities. A Burner Phone in the US may not be Digitally Authenticated, but the NSA in the US has a way to it. AUTOMATED. This can be elaborated as and when the case come up for hearing in the WG, in a formal setting. And if this is not done today due to extensive lobbying efforts by a particular section / Industry members, it will be done as a Mandate tomorrow. We might as well prepare today and keep provisions as the overhaul of the framework and the systems, is inevitable. This is a issue regaining the safety of me, my family, I don¹t think, I am or anybody will be willing to compromise. And the Lives being lost and the Resources being insufficient to tract these anti-social activities are being proven insufficient again and again, there is little contribution we can do to the safety of us. Sincerely, -VA On 7/4/16, 2:57 PM, "Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> wrote:
I disagree. The only party that should be responsible for maintaining good data is the registrant. The responsibilities of registrars, registries and proxy services should revolve only on the correct maintenance of that data and on acting when informed about actual issues with the whois data.
Best,
Volker
Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy services included, so long as contracts are enforced. That isn't the case today as far as I can tell, but with ICANN under new management I think we should hold ICANN, registries, registrars AND proxy providers accountable to provide good data with penalties consistently enforced.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 11:07 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.)
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann .org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro soft.com%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01 1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d _______________________________________________ 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
Dear Catalyst, the only checks that are going to happen are those ingrained in the RAA. It is ultimately the registrants' obligation to provide correct data. Contracted parties will act within their contractual obligations when notified of an issue with the data provided by the registrant or if the data fails the initial sanity check. As for verification: Only email address _or_ phone will be verified upon registration. And while burner phones may be authenticated, no such security exists for throwaway email addresses. But we are getting ahead of ourselves again. Let's keep the discussion of substantive matters to their appropriate time. I just have an issue with the hyperbole used again and again to defend potential infringements into personal privacy rights. /"They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety."/ (Benjamin Franklin, 1775) Best, Volker Greimann Am 04.07.2016 um 11:49 schrieb Catalyst-Vaibhav Aggarwal:
The Responsibility is of the party who is driving profit or providing service. The Registrant is the party who is to be checked for his / her credentials to prevent misuse. The situation is alarming- this is evident of the data being published y various Registries or Governments from time to time related to Bogus Registrations, Misused Domain names cancelled or and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton / Sentinel / MXBlackList / Avast etc such Engines can be referred to for such data collection for the use of consultations. And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. To begin with, the phone is the Personal verified connection by the local authorities. A Burner Phone in the US may not be Digitally Authenticated, but the NSA in the US has a way to it. AUTOMATED.
This can be elaborated as and when the case come up for hearing in the WG, in a formal setting. And if this is not done today due to extensive lobbying efforts by a particular section / Industry members, it will be done as a Mandate tomorrow. We might as well prepare today and keep provisions as the overhaul of the framework and the systems, is inevitable.
This is a issue regaining the safety of me, my family, I don¹t think, I am or anybody will be willing to compromise. And the Lives being lost and the Resources being insufficient to tract these anti-social activities are being proven insufficient again and again, there is little contribution we can do to the safety of us.
Sincerely, -VA
On 7/4/16, 2:57 PM, "Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> wrote:
I disagree. The only party that should be responsible for maintaining good data is the registrant. The responsibilities of registrars, registries and proxy services should revolve only on the correct maintenance of that data and on acting when informed about actual issues with the whois data.
Best,
Volker
Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy services included, so long as contracts are enforced. That isn't the case today as far as I can tell, but with ICANN under new management I think we should hold ICANN, registries, registrars AND proxy providers accountable to provide good data with penalties consistently enforced.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 11:07 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.)
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann .org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro soft.com%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01 1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d _______________________________________________ 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.
That is a complete abdication of responsibilities and contrary to traditional concepts of commercial duties of care. Sent from my iPhone On Jul 4, 2016, at 6:24 AM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Dear Catalyst, the only checks that are going to happen are those ingrained in the RAA. It is ultimately the registrants' obligation to provide correct data. Contracted parties will act within their contractual obligations when notified of an issue with the data provided by the registrant or if the data fails the initial sanity check. As for verification: Only email address _or_ phone will be verified upon registration. And while burner phones may be authenticated, no such security exists for throwaway email addresses. But we are getting ahead of ourselves again. Let's keep the discussion of substantive matters to their appropriate time. I just have an issue with the hyperbole used again and again to defend potential infringements into personal privacy rights. "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." (Benjamin Franklin, 1775) Best, Volker Greimann Am 04.07.2016 um 11:49 schrieb Catalyst-Vaibhav Aggarwal: The Responsibility is of the party who is driving profit or providing service. The Registrant is the party who is to be checked for his / her credentials to prevent misuse. The situation is alarming- this is evident of the data being published y various Registries or Governments from time to time related to Bogus Registrations, Misused Domain names cancelled or and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton / Sentinel / MXBlackList / Avast etc such Engines can be referred to for such data collection for the use of consultations. And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. To begin with, the phone is the Personal verified connection by the local authorities. A Burner Phone in the US may not be Digitally Authenticated, but the NSA in the US has a way to it. AUTOMATED. This can be elaborated as and when the case come up for hearing in the WG, in a formal setting. And if this is not done today due to extensive lobbying efforts by a particular section / Industry members, it will be done as a Mandate tomorrow. We might as well prepare today and keep provisions as the overhaul of the framework and the systems, is inevitable. This is a issue regaining the safety of me, my family, I don¹t think, I am or anybody will be willing to compromise. And the Lives being lost and the Resources being insufficient to tract these anti-social activities are being proven insufficient again and again, there is little contribution we can do to the safety of us. Sincerely, -VA On 7/4/16, 2:57 PM, "Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net><mailto:gnso-rds-pdp-wg-bounces@icann.orgonbehalfofvgreimann@key-systems.net> wrote: I disagree. The only party that should be responsible for maintaining good data is the registrant. The responsibilities of registrars, registries and proxy services should revolve only on the correct maintenance of that data and on acting when informed about actual issues with the whois data. Best, Volker Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg: I think it's perfectly reasonable to expect accurate WhoIs data, proxy services included, so long as contracts are enforced. That isn't the case today as far as I can tell, but with ICANN under new management I think we should hold ICANN, registries, registrars AND proxy providers accountable to provide good data with penalties consistently enforced. -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 11:07 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote: One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored. Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is. I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear. (Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.) 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann .org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro soft.com<http://soft.com>%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01 1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d _______________________________________________ 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
The Name is Aggarwal, Vaibhav Aggarwal. And Friends All over know me as Tiger. Appreciate your response. Best is not be definitive in your approach but be pragmatic :-) As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes. Looking forward to a Interaction with you and build on to it. Cheers -VA From: Volker Greimann <vgreimann@key-systems.net> Date: Monday, July 4, 2016 at 3:52 PM To: Vaibhav Aggarwal <va@bladebrains.com>, <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear Catalyst, the only checks that are going to happen are those ingrained in the RAA. It is ultimately the registrants' obligation to provide correct data. Contracted parties will act within their contractual obligations when notified of an issue with the data provided by the registrant or if the data fails the initial sanity check. As for verification: Only email address _or_ phone will be verified upon registration. And while burner phones may be authenticated, no such security exists for throwaway email addresses. But we are getting ahead of ourselves again. Let's keep the discussion of substantive matters to their appropriate time. I just have an issue with the hyperbole used again and again to defend potential infringements into personal privacy rights. "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." (Benjamin Franklin, 1775) Best, Volker Greimann Am 04.07.2016 um 11:49 schrieb Catalyst-Vaibhav Aggarwal:
The Responsibility is of the party who is driving profit or providing service. The Registrant is the party who is to be checked for his / her credentials to prevent misuse. The situation is alarming- this is evident of the data being published y various Registries or Governments from time to time related to Bogus Registrations, Misused Domain names cancelled or and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton / Sentinel / MXBlackList / Avast etc such Engines can be referred to for such data collection for the use of consultations. And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. To begin with, the phone is the Personal verified connection by the local authorities. A Burner Phone in the US may not be Digitally Authenticated, but the NSA in the US has a way to it. AUTOMATED.
This can be elaborated as and when the case come up for hearing in the WG, in a formal setting. And if this is not done today due to extensive lobbying efforts by a particular section / Industry members, it will be done as a Mandate tomorrow. We might as well prepare today and keep provisions as the overhaul of the framework and the systems, is inevitable.
This is a issue regaining the safety of me, my family, I don¹t think, I am or anybody will be willing to compromise. And the Lives being lost and the Resources being insufficient to tract these anti-social activities are being proven insufficient again and again, there is little contribution we can do to the safety of us.
Sincerely, -VA
On 7/4/16, 2:57 PM, "Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> <mailto:gnso-rds-pdp-wg-bounces@icann.orgonbehalfofvgreimann@key-systems.net> wrote:
I disagree. The only party that should be responsible for maintaining good data is the registrant. The responsibilities of registrars, registries and proxy services should revolve only on the correct maintenance of that data and on acting when informed about actual issues with the whois data.
Best,
Volker
Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy services included, so long as contracts are enforced. That isn't the case today as far as I can tell, but with ICANN under new management I think we should hold ICANN, registries, registrars AND proxy providers accountable to provide good data with penalties consistently enforced.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 11:07 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.)
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.orghttps://na01.safelinks.protection.outlook.com/?url= https%3a%2f%2fmm.icann .org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro soft.com%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01 1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp- wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net <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
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.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-w>> g
-- 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 <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 Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net <http://www.RRPproxy.net> www.domaindiscount24.com <http://www.domaindiscount24.com> / www.BrandShelter.com <http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems <http://www.facebook.com/KeySystems> www.twitter.com/key_systems <http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu <http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Hi, Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works. On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names? Also, On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, Points u have written are baseless and display ur uneasiness of learning about "How Internet works" I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda. Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly. Best regards, -VA Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
I suggest you briefly use Google before saying that Andrew needs to learn how the internet works. For the record I agree with all of andrews points in their entirety. -JG On 04/07/2016, 17:14, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Group CEO-Vaibhav Aggarwal" <gnso-rds-pdp-wg-bounces@icann.org on behalf of va@bladebrains.com> wrote:
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
Dear Vaibhav: Andrew is the Chair of the Internet Architecture Board (IAB), and is a recognized expert on the functioning of the Internet. His questions were respectful, and it is fair for members to question the factual basis of statements made by other members. Sincerely yours, --Greg Aaron ********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 4, 2016 12:15 PM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements) Andrew, Points u have written are baseless and display ur uneasiness of learning about "How Internet works" I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda. Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly. Best regards, -VA Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
Greg, Wud u mean that we shud be scared if presenting pur views in a particular tune, suiting to "Chairs" ?? Or shud v b pragmatic? Accommodating? Truly global. Andrew is a chair for one Comm. We all are some chair some where. And I respect. But, It's unfair to just write and throw weight. It is always important ṭo respect all view points. I have said before, is ICANN about individual whims or collective methodology and approach. I have shown my displeasure in the way Andrew communicated and that's it. Cheers -VA Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:55 PM, Greg Aaron <gca@icginc.com> wrote:
Dear Vaibhav:
Andrew is the Chair of the Internet Architecture Board (IAB), and is a recognized expert on the functioning of the Internet. His questions were respectful, and it is fair for members to question the factual basis of statements made by other members.
Sincerely yours, --Greg Aaron
********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 4, 2016 12:15 PM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
Only if they are factual when claiming facts, otherwise we will falter on the rocks of ignorance all the way through this process. -JG On 04/07/2016, 17:33, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Group CEO-Vaibhav Aggarwal" <gnso-rds-pdp-wg-bounces@icann.org on behalf of va@bladebrains.com> wrote:
It is always important ṭo respect all view points.
When in doubt, counter the argument, do not attack the one making it ;-) Best, Volker Am 04.07.2016 um 18:33 schrieb Group CEO-Vaibhav Aggarwal:
Greg,
Wud u mean that we shud be scared if presenting pur views in a particular tune, suiting to "Chairs" ?? Or shud v b pragmatic? Accommodating? Truly global.
Andrew is a chair for one Comm. We all are some chair some where. And I respect. But, It's unfair to just write and throw weight. It is always important ṭo respect all view points.
I have said before, is ICANN about individual whims or collective methodology and approach.
I have shown my displeasure in the way Andrew communicated and that's it.
Cheers -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:55 PM, Greg Aaron <gca@icginc.com> wrote:
Dear Vaibhav:
Andrew is the Chair of the Internet Architecture Board (IAB), and is a recognized expert on the functioning of the Internet. His questions were respectful, and it is fair for members to question the factual basis of statements made by other members.
Sincerely yours, --Greg Aaron
********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 4, 2016 12:15 PM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes. I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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.
We all have our ways. Some take it literal, some Are open source. I am open to both criticism and suggestion - but when the time is right. The chair in this WG, has and many times, said- we will do it when v do It. Lets nt jump the gun. Arguments are for policy makers, lawyers and likes, Not engineers, Solutions are for engineers !!! ;-) especially v r volunteers :-0 Cheers -VA Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 10:08 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
When in doubt, counter the argument, do not attack the one making it ;-)
Best,
Volker
Am 04.07.2016 um 18:33 schrieb Group CEO-Vaibhav Aggarwal: Greg,
Wud u mean that we shud be scared if presenting pur views in a particular tune, suiting to "Chairs" ?? Or shud v b pragmatic? Accommodating? Truly global.
Andrew is a chair for one Comm. We all are some chair some where. And I respect. But, It's unfair to just write and throw weight. It is always important ṭo respect all view points.
I have said before, is ICANN about individual whims or collective methodology and approach.
I have shown my displeasure in the way Andrew communicated and that's it.
Cheers -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:55 PM, Greg Aaron <gca@icginc.com> wrote:
Dear Vaibhav:
Andrew is the Chair of the Internet Architecture Board (IAB), and is a recognized expert on the functioning of the Internet. His questions were respectful, and it is fair for members to question the factual basis of statements made by other members.
Sincerely yours, --Greg Aaron
********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 4, 2016 12:15 PM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes. I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
We are policy makers not engineers, the engineers have done their work already and are waiting for us to catch up. -JG On 04/07/2016, 17:48, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Group CEO-Vaibhav Aggarwal" <gnso-rds-pdp-wg-bounces@icann.org on behalf of va@bladebrains.com> wrote:
We all have our ways. Some take it literal, some Are open source. I am open to both criticism and suggestion - but when the time is right.
The chair in this WG, has and many times, said- we will do it when v do It. Lets nt jump the gun.
Arguments are for policy makers, lawyers and likes, Not engineers, Solutions are for engineers !!! ;-) especially v r volunteers :-0
Cheers -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 10:08 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
When in doubt, counter the argument, do not attack the one making it ;-)
Best,
Volker
Am 04.07.2016 um 18:33 schrieb Group CEO-Vaibhav Aggarwal: Greg,
Wud u mean that we shud be scared if presenting pur views in a particular tune, suiting to "Chairs" ?? Or shud v b pragmatic? Accommodating? Truly global.
Andrew is a chair for one Comm. We all are some chair some where. And I respect. But, It's unfair to just write and throw weight. It is always important ṭo respect all view points.
I have said before, is ICANN about individual whims or collective methodology and approach.
I have shown my displeasure in the way Andrew communicated and that's it.
Cheers -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:55 PM, Greg Aaron <gca@icginc.com> wrote:
Dear Vaibhav:
Andrew is the Chair of the Internet Architecture Board (IAB), and is a recognized expert on the functioning of the Internet. His questions were respectful, and it is fair for members to question the factual basis of statements made by other members.
Sincerely yours, --Greg Aaron
********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 4, 2016 12:15 PM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes. I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Oh, engineers argue too ;) Sent from my iPhone
On Jul 4, 2016, at 11:51, James Gannon <james@cyberinvasion.net> wrote:
We are policy makers not engineers, the engineers have done their work already and are waiting for us to catch up.
-JG
On 04/07/2016, 17:48, "gnso-rds-pdp-wg-bounces@icann.org on behalf of Group CEO-Vaibhav Aggarwal" <gnso-rds-pdp-wg-bounces@icann.org on behalf of va@bladebrains.com> wrote:
We all have our ways. Some take it literal, some Are open source. I am open to both criticism and suggestion - but when the time is right.
The chair in this WG, has and many times, said- we will do it when v do It. Lets nt jump the gun.
Arguments are for policy makers, lawyers and likes, Not engineers, Solutions are for engineers !!! ;-) especially v r volunteers :-0
Cheers -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 10:08 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
When in doubt, counter the argument, do not attack the one making it ;-)
Best,
Volker
Am 04.07.2016 um 18:33 schrieb Group CEO-Vaibhav Aggarwal: Greg,
Wud u mean that we shud be scared if presenting pur views in a particular tune, suiting to "Chairs" ?? Or shud v b pragmatic? Accommodating? Truly global.
Andrew is a chair for one Comm. We all are some chair some where. And I respect. But, It's unfair to just write and throw weight. It is always important ṭo respect all view points.
I have said before, is ICANN about individual whims or collective methodology and approach.
I have shown my displeasure in the way Andrew communicated and that's it.
Cheers -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:55 PM, Greg Aaron <gca@icginc.com> wrote:
Dear Vaibhav:
Andrew is the Chair of the Internet Architecture Board (IAB), and is a recognized expert on the functioning of the Internet. His questions were respectful, and it is fair for members to question the factual basis of statements made by other members.
Sincerely yours, --Greg Aaron
********************************** Greg Aaron Vice-President, Product Management iThreat Cyber Group / Cybertoolbelt.com mobile: +1.215.858.2257 ********************************** The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 4, 2016 12:15 PM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
> On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote: > > And any such suggestion can easily be implemented with the Automation > of the entire Verification process. For Eg. Gmail has a two Step > Authentication - One on the Password and the other on the Phone > Number of the User. Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
> This is a issue regaining the safety of me, my family Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
> or anybody will be willing to compromise. And the Lives being lost > and the could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
> On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote: > > As far as Security for the Email Addresses is concerned, every email > server has a built in SMTP verification mechanism that either can be > switched on or Off as per the need may be - Most servers or Service > providers don’t switch it on as there is a cost added to their > overall Network Management or Infrastructure. BUT Gmail has > implemented it. That is why we are able to see Classification of Mails in our mail boxes. I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
_______________________________________________ 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
VA, I am having trouble understanding why you had a problem with what or how Andrew said. Could you please help me understand? Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 04, 2016 12:15 PM To: Andrew Sullivan Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements) Andrew, Points u have written are baseless and display ur uneasiness of learning about "How Internet works" I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda. Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly. Best regards, -VA Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don’t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
So V Renaming this WG ??? Charter Re-Drawn ? Nah I am kidding Sorry Chuck, This is gotta wait. I am traveling international till the 10th and this requires Some snippets to be picked up and carefully worded to showcase that Andrew is hedonistic and came down heavily on a personal attack and did not respect a fellow WG-M. I am seeing this getting into a political battle rather than an Intellectual exchange. And I don¹t seem to have time for it. If You want me to exchange Many Pleasantries here, then tell me so and then Tell Everyone So. Then we can all start posting jokes to this list once a while :-) Lets get on with it ! -VA PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately. If this is for that then I am not the kinds who gets pressured. On 7/5/16, 2:33 AM, "Gomes, Chuck" <cgomes@verisign.com> wrote:
VA,
I am having trouble understanding why you had a problem with what or how Andrew said. Could you please help me understand?
Chuck
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 04, 2016 12:15 PM To: Andrew Sullivan Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don¹t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately
Really? Are you guys going so far? Please, Let's focus on our top priority at this moment which is to put our energy together and reach consensus on how to have our list of possible requirements, this to end PDP phase 1. Best Regards --ff-- Mail sent from my mobile phone. Excuse for brievety. Le 4 juil. 2016 22:51, "Catalyst-Vaibhav Aggarwal" <va@bladebrains.com> a écrit :
So V Renaming this WG ??? Charter Re-Drawn ?
Nah I am kiddingŠ
Sorry Chuck, This is gotta wait. I am traveling international till the 10th and this requires Some snippets to be picked up and carefully worded to showcase that Andrew is hedonistic and came down heavily on a personal attack and did not respect a fellow WG-M. I am seeing this getting into a political battle rather than an Intellectual exchange. And I don¹t seem to have time for it.
If You want me to exchange Many Pleasantries here, then tell me so and then Tell Everyone So. Then we can all start posting jokes to this list once a while :-)
Lets get on with it ! -VA
PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately. If this is for that then I am not the kinds who gets pressured.
On 7/5/16, 2:33 AM, "Gomes, Chuck" <cgomes@verisign.com> wrote:
VA,
I am having trouble understanding why you had a problem with what or how Andrew said. Could you please help me understand?
Chuck
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 04, 2016 12:15 PM To: Andrew Sullivan Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don¹t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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 don't have time to address this fully right now due to family and the holiday. I still believe we are way way off course and there are very legitimate concerns about individual security and rights. -------- Original Message -------- On Jul 4, 2016, 4:57 PM, Farell Folly wrote:
PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately
Really? Are you guys going so far? Please, Let's focus on our top priority at this moment which is to put our energy together and reach consensus on how to have our list of possible requirements, this to end PDP phase 1. Best Regards --ff-- Mail sent from my mobile phone. Excuse for brievety. Le 4 juil. 2016 22:51, "Catalyst-Vaibhav Aggarwal" < va@bladebrains.com> a écrit : So V Renaming this WG ??? Charter Re-Drawn ? Nah I am kiddingŠ Sorry Chuck, This is gotta wait. I am traveling international till the 10th and this requires Some snippets to be picked up and carefully worded to showcase that Andrew is hedonistic and came down heavily on a personal attack and did not respect a fellow WG-M. I am seeing this getting into a political battle rather than an Intellectual exchange. And I don¹t seem to have time for it. If You want me to exchange Many Pleasantries here, then tell me so and then Tell Everyone So. Then we can all start posting jokes to this list once a while :-) Lets get on with it ! -VA PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately. If this is for that then I am not the kinds who gets pressured. On 7/5/16, 2:33 AM, "Gomes, Chuck" < cgomes@verisign.com> wrote:
VA,
I am having trouble understanding why you had a problem with what or how Andrew said. Could you please help me understand?
Chuck
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto: gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 04, 2016 12:15 PM To: Andrew Sullivan Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan < ajs@anvilwalrusden.com> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don¹t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
How can we be way off course when we haven’t started deliberating yet? Are you saying that you think the work plan or approach to deliberation is way off course? Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of TXVB Sent: Monday, July 04, 2016 6:09 PM To: farellfolly@gmail.com; va@bladebrains.com Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements) I don't have time to address this fully right now due to family and the holiday. I still believe we are way way off course and there are very legitimate concerns about individual security and rights. -------- Original Message -------- On Jul 4, 2016, 4:57 PM, Farell Folly wrote:
PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately
Really? Are you guys going so far? Please, Let's focus on our top priority at this moment which is to put our energy together and reach consensus on how to have our list of possible requirements, this to end PDP phase 1. Best Regards --ff-- Mail sent from my mobile phone. Excuse for brievety. Le 4 juil. 2016 22:51, "Catalyst-Vaibhav Aggarwal" < va@bladebrains.com<mailto:va@bladebrains.com>> a écrit : So V Renaming this WG ??? Charter Re-Drawn ? Nah I am kiddingŠ Sorry Chuck, This is gotta wait. I am traveling international till the 10th and this requires Some snippets to be picked up and carefully worded to showcase that Andrew is hedonistic and came down heavily on a personal attack and did not respect a fellow WG-M. I am seeing this getting into a political battle rather than an Intellectual exchange. And I don¹t seem to have time for it. If You want me to exchange Many Pleasantries here, then tell me so and then Tell Everyone So. Then we can all start posting jokes to this list once a while :-) Lets get on with it ! -VA PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately. If this is for that then I am not the kinds who gets pressured. On 7/5/16, 2:33 AM, "Gomes, Chuck" < cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote:
VA,
I am having trouble understanding why you had a problem with what or how Andrew said. Could you please help me understand?
Chuck
-----Original Message----- 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 Group CEO-Vaibhav Aggarwal Sent: Monday, July 04, 2016 12:15 PM To: Andrew Sullivan Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan < ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don¹t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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
By starting with requirements, TPTB have set up the various ICANN constituencies to get the result they want via Escalation of commitment (sometimes called commitment bias or the sunk cost fallacy). Do we agree that "abandoning today’s WHOIS model of giving every user the same entirely anonymous public access to (often inaccurate) gTLD registration data. ...basic data would remain publicly available, the rest would be accessible only to accredited requestors who identify themselves, state their purpose, and agree to be held accountable for appropriate use." This should be evaluated on its merits, and THEN if it makes sense, proceed with discussing the requirements for a replacement. We as the NCUC should be the most vocal in fighting for the rights of the non-commercial use of the internet, and as an information secuirty professional, I find the idea of having WHOIS data restricted to "accredited requestors" more than a little concerning - as I forsee it creating a more dangerous internet, with independent research impossible, and For example: per research from the Talos group at Cisco, it can be extrapolated that changes to RDS won't solve the problem. The bad guys are "renting" domains for a day or two, enabled by shady registrar practices. This enables the explosion of malware and spam - individuals/groups are registering domains without private WHOIS, and use stolen or fake information for the registration. Full write up: http://blog.talosintel.com/2016/04/enabling-evil.html From the OSINT.fail blog: "This individual has registered over 4,000 domains in 11 days. I’m sure he/she has reasons, but none that I’m currently interested in hearing. Not surprisingly, the actor is also associated with over 100K other active domains. " http://www.osint.fail/2016/02/29/large-foot-prints-and-loud-noises/ The current Registrar Agreements require complete and accurate information - do we believe setting up a whole new RDS will prevent bad actors from exploiting loopholes, or would enforcing current policy on bad registrars suffice? Will a new NG-RDS solve this? I doubt it. Existing policies and law enforcement organizations either can't or won't enforce the law and rules, the good guys doing research, many aggressively paranoid about privacy, find themselves unable to access data to do research, unwilling to disclose their identities due to personal beliefs to access the data, or most likely both. The question was asked:
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Yes. Activists, protesters, and minorities could find themselves targeted, with anti-privacy, or oppressive governments with policies such as proposed by the UK Draft Communications Data Bill (sometimes called the Snooper's Charter) would make it difficult, if not impossible to build a private, pseudonymous structure for communication outside of the "approved channels" As it will be impossible in any NG-RDS to keep Governments out of this new structure. As seen by even the most supposedly "free" countries, the Governments are drooling at the idea of getting more data and monitoring of any time implemented everywhere. https://keybase.io/txvb/key.asc Fingerprint: 8D6F514FCF40BEB6E3F5C8835B2CD1B4FE6A8562 -------------------------------------------------------- READ CAREFULLY. By [reading this email|accepting this material|accepting this payment|accepting this business-card|viewing this t-shirt|reading this sticker] you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (“BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. For avoidance of doubt: This email does not constitute permission to add me to your mailing list. -------- Original Message -------- Subject: RE: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements) Local Time: July 4, 2016 5:42 PM UTC Time: July 4, 2016 10:42 PM From: cgomes@verisign.com To: ncuc@jollyrogers.email,farellfolly@gmail.com,va@bladebrains.com CC: gnso-rds-pdp-wg@icann.org How can we be way off course when we haven’t started deliberating yet? Are you saying that you think the work plan or approach to deliberation is way off course? Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of TXVB Sent: Monday, July 04, 2016 6:09 PM To: farellfolly@gmail.com; va@bladebrains.com Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements) I don't have time to address this fully right now due to family and the holiday. I still believe we are way way off course and there are very legitimate concerns about individual security and rights. -------- Original Message -------- On Jul 4, 2016, 4:57 PM, Farell Folly wrote:
PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately
Really? Are you guys going so far? Please, Let's focus on our top priority at this moment which is to put our energy together and reach consensus on how to have our list of possible requirements, this to end PDP phase 1. Best Regards --ff-- Mail sent from my mobile phone. Excuse for brievety. Le 4 juil. 2016 22:51, "Catalyst-Vaibhav Aggarwal" < [ va@bladebrains.com](mailto:va@bladebrains.com)> a écrit : So V Renaming this WG ??? Charter Re-Drawn ? Nah I am kiddingŠ Sorry Chuck, This is gotta wait. I am traveling international till the 10th and this requires Some snippets to be picked up and carefully worded to showcase that Andrew is hedonistic and came down heavily on a personal attack and did not respect a fellow WG-M. I am seeing this getting into a political battle rather than an Intellectual exchange. And I don¹t seem to have time for it. If You want me to exchange Many Pleasantries here, then tell me so and then Tell Everyone So. Then we can all start posting jokes to this list once a while :-) Lets get on with it ! -VA PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately. If this is for that then I am not the kinds who gets pressured. On 7/5/16, 2:33 AM, "Gomes, Chuck" < cgomes@verisign.com> wrote:
VA,
I am having trouble understanding why you had a problem with what or how Andrew said. Could you please help me understand?
Chuck
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto: gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Group CEO-Vaibhav Aggarwal Sent: Monday, July 04, 2016 12:15 PM To: Andrew Sullivan Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] On some security claims (was Re: Apologies, and some reflections on requirements)
Andrew,
Points u have written are baseless and display ur uneasiness of learning about "How Internet works"
I won't present a retort here which is targeted to a specific individual and not try to waste anyone's time in reading. But if u are a internet conneseiur, then u wud never write a baseless argument over a suggestion. So I request back off and stick to the agenda.
Lets keep the nice nodes open to data exchange and not block the speed by writing baselessly.
Best regards, -VA
Sent from my mobile device. Typos regretted.
On Jul 4, 2016, at 9:30 PM, Andrew Sullivan < [ ajs@anvilwalrusden.com](mailto:ajs@anvilwalrusden.com)> wrote:
Hi,
Responding to two messages at once. I think there are some technical misconceptions in the messages from Catalyst-Vaibhav Aggarwal. We won't get anywhere if we proceed by believing false things about how the Internet works.
On Mon, Jul 04, 2016 at 03:19:53PM +0530, Catalyst-Vaibhav Aggarwal wrote:
And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User.
Actually, no. What Google two-step authentication does is bind a login to both a password and some other communication factor. It does not actually tell you who is at the other end, and can't. There is a serious and important difference for our purposes between authenticating that the same indvidual is undertaking two different actions, and identifying who that individual is when (e.g.) wandering around in the street.
This is a issue regaining the safety of me, my family
Can you say more about how you think registration of domain names in the global DNS could (even a little bit) affect the safety of you or your family? In particular,
or anybody will be willing to compromise. And the Lives being lost and the
could you say some more about how you think anyone's life hangs in the balance due to registration of domain names?
Also,
On Mon, Jul 04, 2016 at 04:28:29PM +0530, Catalyst-Vaibhav Aggarwal wrote:
As far as Security for the Email Addresses is concerned, every email server has a built in SMTP verification mechanism that either can be switched on or Off as per the need may be - Most servers or Service providers don¹t switch it on as there is a cost added to their overall Network Management or Infrastructure. BUT Gmail has implemented it. That is why we are able to see Classification of Mails in our mail boxes.
I would appreciate a pointer to the documentation of this SMTP verification mechanism of which you speak. I'm reasonably familiar with the SMTP specifications, and I'm not really sure what feature you're talking about. If you mean the SMTP VRFY verb, I don't think it does what you think it does, and it has been widely regarded as a spam-promoting feature since at least 1999. It is certainly not the basis for Google's classification of your email, which (depending on how you use it) depends on them reading either your headers or your mail bodies to classify it for you.
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](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](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, Jul 05, 2016 at 03:17:42AM +0530, Catalyst-Vaibhav Aggarwal wrote:
PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately. If this is for that then I am not the kinds who gets pressured.
For the record, I did send a note off-list, which I started in the usual way with "offlist" to make it clear that I was intending to take communication private -- because it didn't seem like something worth bothering the list with. I see that effort has failed. If it is useful to the Chairs I will cheerfully forward that off-list note to them (copying the original correspondent for transparency); but I think the WG has had rather enough of this topic already. I regret having responded in the first place, and I wouldn't have except for the apparent prevalence, when it comes to the topic of RDS, of all manner of fanciful ideas about what is and is not technically possible on the Internet. I do hope that other participants, noting that not a single one of my original questions has been answered, will take the assertions I was asking about to be supported by exactly as much evidence as has been presented. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
We really appreciate you responding on all technical matters Andrew, because it is difficult for those of us who are not technical to know when we are operating under or accepting false assumptions. Please don't stop. Let's all try to refrain from getting over-heated, it is going to be a long five years if we start taking things personally now. Stephanie Perrin On 2016-07-04 19:29, Andrew Sullivan wrote:
On Tue, Jul 05, 2016 at 03:17:42AM +0530, Catalyst-Vaibhav Aggarwal wrote:
PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately. If this is for that then I am not the kinds who gets pressured. For the record, I did send a note off-list, which I started in the usual way with "offlist" to make it clear that I was intending to take communication private -- because it didn't seem like something worth bothering the list with. I see that effort has failed.
If it is useful to the Chairs I will cheerfully forward that off-list note to them (copying the original correspondent for transparency); but I think the WG has had rather enough of this topic already. I regret having responded in the first place, and I wouldn't have except for the apparent prevalence, when it comes to the topic of RDS, of all manner of fanciful ideas about what is and is not technically possible on the Internet.
I do hope that other participants, noting that not a single one of my original questions has been answered, will take the assertions I was asking about to be supported by exactly as much evidence as has been presented.
Best regards,
A
+1 Sent from my mobile device. Typos regretted.
On Jul 5, 2016, at 6:05 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote:
We really appreciate you responding on all technical matters Andrew, because it is difficult for those of us who are not technical to know when we are operating under or accepting false assumptions. Please don't stop. Let's all try to refrain from getting over-heated, it is going to be a long five years if we start taking things personally now. Stephanie Perrin
On 2016-07-04 19:29, Andrew Sullivan wrote:
On Tue, Jul 05, 2016 at 03:17:42AM +0530, Catalyst-Vaibhav Aggarwal wrote: PS : If you want, I can forward the Mail Andrew Sent me threatening me to get me ³Offlist² Separately. If this is for that then I am not the kinds who gets pressured. For the record, I did send a note off-list, which I started in the usual way with "offlist" to make it clear that I was intending to take communication private -- because it didn't seem like something worth bothering the list with. I see that effort has failed.
If it is useful to the Chairs I will cheerfully forward that off-list note to them (copying the original correspondent for transparency); but I think the WG has had rather enough of this topic already. I regret having responded in the first place, and I wouldn't have except for the apparent prevalence, when it comes to the topic of RDS, of all manner of fanciful ideas about what is and is not technically possible on the Internet.
I do hope that other participants, noting that not a single one of my original questions has been answered, will take the assertions I was asking about to be supported by exactly as much evidence as has been presented.
Best regards,
A
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Catalyst, hi- I agree that we all have a responsibility to address Internet security issues. However, in doing so, I would like to put forward that we all have a responsibility to respect fundamental human rights and values, including the right to privacy. We will never be able to entirely eliminate the threats posed by bad actors. As you said, fake email addresses and burner phones are all possibilities today. If we put too many barriers in place to registering a domain name, we are not going to stop those who are registering domain names for malicious purposes. They will always find ways to get content online. We will hurt and inconvenience only well-meaning and law-abiding citizens who rely on domain names to express their ideas, to manage their micro enterprise, or to otherwise engage in lawful activities. In all that we do as a working group I would like us to foster confidence in the Internet and to protect opportunities online for economic and social prosperity. Best wishes, Ayden On Mon, Jul 4, 2016 10:49 AM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote: The Responsibility is of the party who is driving profit or providing service. The Registrant is the party who is to be checked for his / her credentials to prevent misuse. The situation is alarming- this is evident of the data being published y various Registries or Governments from time to time related to Bogus Registrations, Misused Domain names cancelled or and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton / Sentinel / MXBlackList / Avast etc such Engines can be referred to for such data collection for the use of consultations. And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. To begin with, the phone is the Personal verified connection by the local authorities. A Burner Phone in the US may not be Digitally Authenticated, but the NSA in the US has a way to it. AUTOMATED. This can be elaborated as and when the case come up for hearing in the WG, in a formal setting. And if this is not done today due to extensive lobbying efforts by a particular section / Industry members, it will be done as a Mandate tomorrow. We might as well prepare today and keep provisions as the overhaul of the framework and the systems, is inevitable. This is a issue regaining the safety of me, my family, I don¹t think, I am or anybody will be willing to compromise. And the Lives being lost and the Resources being insufficient to tract these anti-social activities are being proven insufficient again and again, there is little contribution we can do to the safety of us. Sincerely, -VA On 7/4/16, 2:57 PM, "Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net> wrote:
I disagree. The only party that should be responsible for maintaining
good data is the registrant. The responsibilities of registrars,
registries and proxy services should revolve only on the correct
maintenance of that data and on acting when informed about actual issues
with the whois data.
Best,
Volker
Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy
services included, so long as contracts are enforced. That isn't the
case today as far as I can tell, but with ICANN under new management I
think we should hold ICANN, registries, registrars AND proxy providers
accountable to provide good data with penalties consistently enforced.
-----Original Message-----
From: gnso-rds-pdp-wg-bounces@icann.org
[mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan
Sent: Thursday, June 30, 2016 11:07 PM
To: gnso-rds-pdp-wg@icann.org
Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on
requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it
with: privacy proxy services can sit between the registrant and
registrar - Andrew's models didn't explicitly mention that. Keep
that in mind when we discuss what is collected, who its shared with,
and where its stored.
Well, yes, but from the point of view of the registration system the
registrant is actually the proxy service. The "real" registrant in
effect has an agreement with the proxy service that the proxy service
will abide by the "real" registrant's instructions. It's a matter of
contract whether that happens, of course -- the registrar simply can't
tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of
the reason why I think the entire "accurate whois data" shuffle is such
an absurd waste of time. There is literally no way to prevent these
kinds of proxy registrations from happening, because the actual proxy
activity happens outside the registration context. One can of course
make them more expensive with increasingly baroque rules, but that's not
the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments
in some jurisdictions in order to see why this is the case.)
Best regards,
A
--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann
.org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro
soft.com%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01
1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns
per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact
us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay
updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom
it is addressed. Furthermore it is not permitted to publish any content
of this email. You must not use, disclose, copy, print or rely on this
e-mail. If an addressing or transmission error has misdirected this
e-mail, kindly notify the author by replying to this e-mail or contacting
us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg Ayden Férdeline Statement of Interest
Ayden, 1. The Name is Vaibhav Aggarwal for your reference. 2. The Fostering responsibility is to inculcated at all levels. Crony capitalism cannot drive security – but global studies have demonstrated Security drives policy which drives businesses. Businesses always adapt, policy doesn't. 2a. Privacy or Data Security point is perfectly brought. Severe penalties should be built in onto businesses and legal liabilities be created in line with the laws of the land, for leaks in data. Any verified data is protected by a private and confidential clause in the service agreement with the customer. 3. Well meaning and Law Abiding Citizens always are up for easy forms of verifications. And Such data will be available in Studies globally in different countries, Diff. industries, diff. environments and situations and they are happy to accommodate; Lets deliberate in the time to come. This is a vast topic but specific, Mr. M.M.Oberoi (INDIAN POLICE SERVICE)– Cyber Security Head of Interpol Asia is at Singapore – I also recommend people like him can be roped in. I know that people from US agencies like the CIA and NSA and FBI Cyber Division, and the other countries will be more than willing to contribute to this, if need be. I have friends, will be happy to help. Regards, -VA From: Ayden Férdeline <icann@ferdeline.com> Date: Monday, July 4, 2016 at 4:19 PM To: Vaibhav Aggarwal <va@bladebrains.com> Cc: Volker Greimann <vgreimann@key-systems.net>, <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Catalyst, hi- I agree that we all have a responsibility to address Internet security issues. However, in doing so, I would like to put forward that we all have a responsibility to respect fundamental human rights and values, including the right to privacy. We will never be able to entirely eliminate the threats posed by bad actors. As you said, fake email addresses and burner phones are all possibilities today. If we put too many barriers in place to registering a domain name, we are not going to stop those who are registering domain names for malicious purposes. They will always find ways to get content online. We will hurt and inconvenience only well-meaning and law-abiding citizens who rely on domain names to express their ideas, to manage their micro enterprise, or to otherwise engage in lawful activities. In all that we do as a working group I would like us to foster confidence in the Internet and to protect opportunities online for economic and social prosperity. Best wishes, Ayden On Mon, Jul 4, 2016 10:49 AM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote:
The Responsibility is of the party who is driving profit or providing
service. The Registrant is the party who is to be checked for his / her
credentials to prevent misuse. The situation is alarming- this is evident
of the data being published y various Registries or Governments from time
to time related to Bogus Registrations, Misused Domain names cancelled or
and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton /
Sentinel / MXBlackList / Avast etc such Engines can be referred to for
such data collection for the use of consultations.
And any such suggestion can easily be implemented with the Automation of
the entire Verification process. For Eg. Gmail has a two Step
Authentication - One on the Password and the other on the Phone Number of
the User. To begin with, the phone is the Personal verified connection by
the local authorities. A Burner Phone in the US may not be Digitally
Authenticated, but the NSA in the US has a way to it. AUTOMATED.
This can be elaborated as and when the case come up for hearing in the WG,
in a formal setting. And if this is not done today due to extensive
lobbying efforts by a particular section / Industry members, it will be
done as a Mandate tomorrow. We might as well prepare today and keep
provisions as the overhaul of the framework and the systems, is inevitable.
This is a issue regaining the safety of me, my family, I don¹t think, I am
or anybody will be willing to compromise. And the Lives being lost and the
Resources being insufficient to tract these anti-social activities are
being proven insufficient again and again, there is little contribution we
can do to the safety of us.
Sincerely,
-VA
On 7/4/16, 2:57 PM, "Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org
on behalf of vgreimann@key-systems.net> wrote:
I disagree. The only party that should be responsible for maintaining
good data is the registrant. The responsibilities of registrars,
registries and proxy services should revolve only on the correct
maintenance of that data and on acting when informed about actual issues
with the whois data.
Best,
Volker
Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy
services included, so long as contracts are enforced. That isn't the
case today as far as I can tell, but with ICANN under new management I
think we should hold ICANN, registries, registrars AND proxy providers
accountable to provide good data with penalties consistently enforced.
-----Original Message-----
From: gnso-rds-pdp-wg-bounces@icann.org
[mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan
Sent: Thursday, June 30, 2016 11:07 PM
To: gnso-rds-pdp-wg@icann.org
Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on
requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
> One more comment regarding who collects the data and who they share it
>with: privacy proxy services can sit between the registrant and
>registrar - Andrew's models didn't explicitly mention that. Keep
>that in mind when we discuss what is collected, who its shared with,
>and where its stored.
>
Well, yes, but from the point of view of the registration system the
registrant is actually the proxy service. The "real" registrant in
effect has an agreement with the proxy service that the proxy service
will abide by the "real" registrant's instructions. It's a matter of
contract whether that happens, of course -- the registrar simply can't
tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of
the reason why I think the entire "accurate whois data" shuffle is such
an absurd waste of time. There is literally no way to prevent these
kinds of proxy registrations from happening, because the actual proxy
activity happens outside the registration context. One can of course
make them more expensive with increasingly baroque rules, but that's not
the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments
in some jurisdictions in order to see why this is the case.)
Best regards,
A
--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann
.org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro
soft.com%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01
1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns
per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact
us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay
updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom
it is addressed. Furthermore it is not permitted to publish any content
of this email. You must not use, disclose, copy, print or rely on this
e-mail. If an addressing or transmission error has misdirected this
e-mail, kindly notify the author by replying to this e-mail or contacting
us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
Ayden Férdeline Statement of Interest <https://community.icann.org/display/gnsosoi/Ayden+Férdeline+SOI>
VA, hi- I apologise for getting your name wrong in my previous message. I appreciate that we have approached this issue from different perspectives, but I do not accept that security strategies must trump individual freedoms. In particular, I disagree with your suggestion that “security drives policy which drives business.” I would like to put forward that the opposite is true – red tape hinders business, it does not drive it. In my view, policy should be set only when there is an outcome that is either desired or should be prevented. If I take your example, that having an accurate directory of contact information for registrants is desirable from the perspective of maintaining law and order online, I would like to suggest that restricting one’s ability to register a domain name unless they provide verified personal data is a poor means of achieving your desired goal. It might well have significant collateral damage for, say, those blogging against repressive governments. I agree with you that the security of the Internet is a responsibility that we all share. We will all be secure only when we are protecting ourselves, our neighbours, the vulnerable, etc… So for this reason I have to say that I object to your characterisation of only those persons prepared to sacrifice their fundamental right to privacy as being “well-meaning and law-abiding citizens”. I refer you to this public comment by Karl Auerbach in 2006, where he noted that, “The Whois database for DNS names has already caused real and substantial harm. Every one of us has received spam and phone calls based on whois data. But the harm goes much deeper. It goes so deep that women have been stalked based on DNS whois data. It goes so deep that families who use the internet to communicate are forced by DNS whois to expose their names, their addresses, their phone numbers, their afilliations - not just of parents but also of their children - to anyone, including predators, 24x7x365.” These are people who I would classify as well-meaning and law-abiding citizens. A security ‘solution’ which does not foster confidence in the Internet, but causes more harm than good, is not something I would be comfortable supporting. Finally, I’m not sure what the “laws of the land” are which you refer to? We haven’t even agreed on whether data should be localised, distributed, federated… so we are jumping a head a little. I presume you are referring to national laws, and if so, I would like to add that I do not want ICANN to be involved in questions to do with jurisdiction, and certainly not until such time as global tensions around ensuring due process for all, and respecting human rights in online contexts, are resolved. I am imagining a scenario where we determine, say, we will have gated access for individuals (and I fully appreciate that we have yet to enter into deliberations on this front… this is simply an example). If a website’s owner is based, say, in Taiwan, their website is hosted on a server in Canada, the webhost is incorporated in Panama, their domain name registrar is in the Netherlands, and ICANN’s central repository of registration data is in the United States (if we went with a federated approach); what would happen if a request was received from law enforcement in China requesting the registrant’s personal data? Should it be fulfilled, even if there was reasonable suspicion that it would result in harm to the registrant? This may seem an extreme example but I suspect there will be overlapping if not conflicting territorial criteria somewhere along the way that is going to risk destroying the nature and benefits that the Internet, as a global network of networks, has brought about, and so we should steer well clear of any such discussions. So please. Let us avoid questions of jurisdiction, and not sacrifice our fundamental rights, freedoms and values in order to maintain ‘security’. I like the Benjamin Franklin quote that Volker ended his email with. It's very fitting. Best wishes, Ayden On Mon, Jul 4, 2016 12:13 PM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote: Ayden, 1. The Name is Vaibhav Aggarwal for your reference. 2. The Fostering responsibility is to inculcated at all levels. Crony capitalism cannot drive security – but global studies have demonstrated Security drives policy which drives businesses. Businesses always adapt, policy doesn't. 2a. Privacy or Data Security point is perfectly brought. Severe penalties should be built in onto businesses and legal liabilities be created in line with the laws of the land, for leaks in data. Any verified data is protected by a private and confidential clause in the service agreement with the customer. 3. Well meaning and Law Abiding Citizens always are up for easy forms of verifications. And Such data will be available in Studies globally in different countries, Diff. industries, diff. environments and situations and they are happy to accommodate; Lets deliberate in the time to come. This is a vast topic but specific, Mr. M.M.Oberoi (INDIAN POLICE SERVICE)– Cyber Security Head of Interpol Asia is at Singapore – I also recommend people like him can be roped in. I know that people from US agencies like the CIA and NSA and FBI Cyber Division, and the other countries will be more than willing to contribute to this, if need be. I have friends, will be happy to help. Regards, -VA From: Ayden Férdeline < icann@ferdeline.com > Date: Monday, July 4, 2016 at 4:19 PM To: Vaibhav Aggarwal < va@bladebrains.com > Cc: Volker Greimann < vgreimann@key-systems.net >, < gnso-rds-pdp-wg@icann.org > Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Catalyst, hi- I agree that we all have a responsibility to address Internet security issues. However, in doing so, I would like to put forward that we all have a responsibility to respect fundamental human rights and values, including the right to privacy. We will never be able to entirely eliminate the threats posed by bad actors. As you said, fake email addresses and burner phones are all possibilities today. If we put too many barriers in place to registering a domain name, we are not going to stop those who are registering domain names for malicious purposes. They will always find ways to get content online. We will hurt and inconvenience only well-meaning and law-abiding citizens who rely on domain names to express their ideas, to manage their micro enterprise, or to otherwise engage in lawful activities. In all that we do as a working group I would like us to foster confidence in the Internet and to protect opportunities online for economic and social prosperity. Best wishes, Ayden On Mon, Jul 4, 2016 10:49 AM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote: The Responsibility is of the party who is driving profit or providing service. The Registrant is the party who is to be checked for his / her credentials to prevent misuse. The situation is alarming- this is evident of the data being published y various Registries or Governments from time to time related to Bogus Registrations, Misused Domain names cancelled or and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton / Sentinel / MXBlackList / Avast etc such Engines can be referred to for such data collection for the use of consultations. And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. To begin with, the phone is the Personal verified connection by the local authorities. A Burner Phone in the US may not be Digitally Authenticated, but the NSA in the US has a way to it. AUTOMATED. This can be elaborated as and when the case come up for hearing in the WG, in a formal setting. And if this is not done today due to extensive lobbying efforts by a particular section / Industry members, it will be done as a Mandate tomorrow. We might as well prepare today and keep provisions as the overhaul of the framework and the systems, is inevitable. This is a issue regaining the safety of me, my family, I don¹t think, I am or anybody will be willing to compromise. And the Lives being lost and the Resources being insufficient to tract these anti-social activities are being proven insufficient again and again, there is little contribution we can do to the safety of us. Sincerely, -VA On 7/4/16, 2:57 PM, "Volker Greimann" < gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net > wrote:
I disagree. The only party that should be responsible for maintaining
good data is the registrant. The responsibilities of registrars,
registries and proxy services should revolve only on the correct
maintenance of that data and on acting when informed about actual issues
with the whois data.
Best,
Volker
Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy
services included, so long as contracts are enforced. That isn't the
case today as far as I can tell, but with ICANN under new management I
think we should hold ICANN, registries, registrars AND proxy providers
accountable to provide good data with penalties consistently enforced.
-----Original Message-----
From: gnso-rds-pdp-wg-bounces@icann.org
[ mailto:gnso-rds-pdp-wg-bounces@icann.org ] On Behalf Of Andrew Sullivan
Sent: Thursday, June 30, 2016 11:07 PM
To: gnso-rds-pdp-wg@icann.org
Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on
requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it
with: privacy proxy services can sit between the registrant and
registrar - Andrew's models didn't explicitly mention that. Keep
that in mind when we discuss what is collected, who its shared with,
and where its stored.
Well, yes, but from the point of view of the registration system the
registrant is actually the proxy service. The "real" registrant in
effect has an agreement with the proxy service that the proxy service
will abide by the "real" registrant's instructions. It's a matter of
contract whether that happens, of course -- the registrar simply can't
tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of
the reason why I think the entire "accurate whois data" shuffle is such
an absurd waste of time. There is literally no way to prevent these
kinds of proxy registrations from happening, because the actual proxy
activity happens outside the registration context. One can of course
make them more expensive with increasingly baroque rules, but that's not
the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments
in some jurisdictions in order to see why this is the case.)
Best regards,
A
--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann
.org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro
soft.com%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01
1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns
per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact
us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay
updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom
it is addressed. Furthermore it is not permitted to publish any content
of this email. You must not use, disclose, copy, print or rely on this
e-mail. If an addressing or transmission error has misdirected this
e-mail, kindly notify the author by replying to this e-mail or contacting
us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg Ayden Férdeline Statement of Interest Ayden Férdeline Statement of Interest
Nice work, Great mail. It seems I can’t compete with you on the time limitation that I have. So I would apologize that I will not be able to go through this, but as a member of this WG, I am sure it would be useful. The Chair, you have a lot of work to do and we will all keep you on your toes :-) Best wishes, -Vaibhav Aggarwal From: Ayden Férdeline <icann@ferdeline.com> Date: Monday, July 4, 2016 at 5:21 PM To: Vaibhav Aggarwal <va@bladebrains.com> Cc: Volker Greimann <vgreimann@key-systems.net>, <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements VA, hi- I apologise for getting your name wrong in my previous message. I appreciate that we have approached this issue from different perspectives, but I do not accept that security strategies must trump individual freedoms. In particular, I disagree with your suggestion that “security drives policy which drives business.” I would like to put forward that the opposite is true – red tape hinders business, it does not drive it. In my view, policy should be set only when there is an outcome that is either desired or should be prevented. If I take your example, that having an accurate directory of contact information for registrants is desirable from the perspective of maintaining law and order online, I would like to suggest that restricting one’s ability to register a domain name unless they provide verified personal data is a poor means of achieving your desired goal. It might well have significant collateral damage for, say, those blogging against repressive governments. I agree with you that the security of the Internet is a responsibility that we all share. We will all be secure only when we are protecting ourselves, our neighbours, the vulnerable, etc… So for this reason I have to say that I object to your characterisation of only those persons prepared to sacrifice their fundamental right to privacy as being “well-meaning and law-abiding citizens”. I refer you to this public comment by Karl Auerbach <https://links2.mixmaxusercontent.com/aMjjKHWxnLSD3SEwj/l/zd3fjNQMKBXpLJwTb? messageId=IS33XzDCWiKIPfJgK&rn=iwWY3JXYndWQgYXYoJWahZVL0NXesFGdhNkI&re=ISbvN mLz5WahJnYlRWYsJGQhZnI> in 2006, where he noted that, “The Whois database for DNS names has already caused real and substantial harm. Every one of us has received spam and phone calls based on whois data. But the harm goes much deeper. It goes so deep that women have been stalked based on DNS whois data. It goes so deep that families who use the internet to communicate are forced by DNS whois to expose their names, their addresses, their phone numbers, their afilliations - not just of parents but also of their children - to anyone, including predators, 24x7x365.” These are people who I would classify as well-meaning and law-abiding citizens. A security ‘solution’ which does not foster confidence in the Internet, but causes more harm than good, is not something I would be comfortable supporting. Finally, I’m not sure what the “laws of the land” are which you refer to? We haven’t even agreed on whether data should be localised, distributed, federated… so we are jumping a head a little. I presume you are referring to national laws, and if so, I would like to add that I do not want ICANN to be involved in questions to do with jurisdiction, and certainly not until such time as global tensions around ensuring due process for all, and respecting human rights in online contexts, are resolved. I am imagining a scenario where we determine, say, we will have gated access for individuals (and I fully appreciate that we have yet to enter into deliberations on this front… this is simply an example). If a website’s owner is based, say, in Taiwan, their website is hosted on a server in Canada, the webhost is incorporated in Panama, their domain name registrar is in the Netherlands, and ICANN’s central repository of registration data is in the United States (if we went with a federated approach); what would happen if a request was received from law enforcement in China requesting the registrant’s personal data? Should it be fulfilled, even if there was reasonable suspicion that it would result in harm to the registrant? This may seem an extreme example but I suspect there will be overlapping if not conflicting territorial criteria somewhere along the way that is going to risk destroying the nature and benefits that the Internet, as a global network of networks, has brought about, and so we should steer well clear of any such discussions. So please. Let us avoid questions of jurisdiction, and not sacrifice our fundamental rights, freedoms and values in order to maintain ‘security’. I like the Benjamin Franklin quote that Volker ended his email with. It's very fitting. Best wishes, Ayden On Mon, Jul 4, 2016 12:13 PM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote:
Ayden, 1. The Name is Vaibhav Aggarwal for your reference. 2. The Fostering responsibility is to inculcated at all levels. Crony capitalism cannot drive security – but global studies have demonstrated Security drives policy which drives businesses. Businesses always adapt, policy doesn't. 2a. Privacy or Data Security point is perfectly brought. Severe penalties should be built in onto businesses and legal liabilities be created in line with the laws of the land, for leaks in data. Any verified data is protected by a private and confidential clause in the service agreement with the customer. 3. Well meaning and Law Abiding Citizens always are up for easy forms of verifications. And Such data will be available in Studies globally in different countries, Diff. industries, diff. environments and situations and they are happy to accommodate;
Lets deliberate in the time to come. This is a vast topic but specific, Mr. M.M.Oberoi (INDIAN POLICE SERVICE)– Cyber Security Head of Interpol Asia is at Singapore – I also recommend people like him can be roped in. I know that people from US agencies like the CIA and NSA and FBI Cyber Division, and the other countries will be more than willing to contribute to this, if need be. I have friends, will be happy to help.
Regards, -VA
From: Ayden Férdeline <icann@ferdeline.com> Date: Monday, July 4, 2016 at 4:19 PM To: Vaibhav Aggarwal <va@bladebrains.com> Cc: Volker Greimann <vgreimann@key-systems.net>, <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Catalyst, hi-
I agree that we all have a responsibility to address Internet security issues. However, in doing so, I would like to put forward that we all have a responsibility to respect fundamental human rights and values, including the right to privacy.
We will never be able to entirely eliminate the threats posed by bad actors. As you said, fake email addresses and burner phones are all possibilities today. If we put too many barriers in place to registering a domain name, we are not going to stop those who are registering domain names for malicious purposes. They will always find ways to get content online. We will hurt and inconvenience only well-meaning and law-abiding citizens who rely on domain names to express their ideas, to manage their micro enterprise, or to otherwise engage in lawful activities.
In all that we do as a working group I would like us to foster confidence in the Internet and to protect opportunities online for economic and social prosperity.
Best wishes,
Ayden
On Mon, Jul 4, 2016 10:49 AM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote:
The Responsibility is of the party who is driving profit or providing
service. The Registrant is the party who is to be checked for his / her
credentials to prevent misuse. The situation is alarming- this is evident
of the data being published y various Registries or Governments from time
to time related to Bogus Registrations, Misused Domain names cancelled or
and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton /
Sentinel / MXBlackList / Avast etc such Engines can be referred to for
such data collection for the use of consultations.
And any such suggestion can easily be implemented with the Automation of
the entire Verification process. For Eg. Gmail has a two Step
Authentication - One on the Password and the other on the Phone Number of
the User. To begin with, the phone is the Personal verified connection by
the local authorities. A Burner Phone in the US may not be Digitally
Authenticated, but the NSA in the US has a way to it. AUTOMATED.
This can be elaborated as and when the case come up for hearing in the WG,
in a formal setting. And if this is not done today due to extensive
lobbying efforts by a particular section / Industry members, it will be
done as a Mandate tomorrow. We might as well prepare today and keep
provisions as the overhaul of the framework and the systems, is inevitable.
This is a issue regaining the safety of me, my family, I don¹t think, I am
or anybody will be willing to compromise. And the Lives being lost and the
Resources being insufficient to tract these anti-social activities are
being proven insufficient again and again, there is little contribution we
can do to the safety of us.
Sincerely,
-VA
On 7/4/16, 2:57 PM, "Volker Greimann" <gnso-rds-pdp-wg-bounces@icann.org
on behalf of vgreimann@key-systems.net> wrote:
I disagree. The only party that should be responsible for maintaining
good data is the registrant. The responsibilities of registrars,
registries and proxy services should revolve only on the correct
maintenance of that data and on acting when informed about actual issues
with the whois data.
Best,
Volker
Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy
services included, so long as contracts are enforced. That isn't the
case today as far as I can tell, but with ICANN under new management I
think we should hold ICANN, registries, registrars AND proxy providers
accountable to provide good data with penalties consistently enforced.
-----Original Message-----
From: gnso-rds-pdp-wg-bounces@icann.org
[mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan
Sent: Thursday, June 30, 2016 11:07 PM
To: gnso-rds-pdp-wg@icann.org
Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on
requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
>> One more comment regarding who collects the data and who they share it
>>with: privacy proxy services can sit between the registrant and
>>registrar - Andrew's models didn't explicitly mention that. Keep
>>that in mind when we discuss what is collected, who its shared with,
>>and where its stored.
>>
Well, yes, but from the point of view of the registration system the
registrant is actually the proxy service. The "real" registrant in
effect has an agreement with the proxy service that the proxy service
will abide by the "real" registrant's instructions. It's a matter of
contract whether that happens, of course -- the registrar simply can't
tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of
the reason why I think the entire "accurate whois data" shuffle is such
an absurd waste of time. There is literally no way to prevent these
kinds of proxy registrations from happening, because the actual proxy
activity happens outside the registration context. One can of course
make them more expensive with increasingly baroque rules, but that's not
the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments
in some jurisdictions in order to see why this is the case.)
Best regards,
A
--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann
.org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro
soft.com%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01
1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns
per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact
us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay
updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom
it is addressed. Furthermore it is not permitted to publish any content
of this email. You must not use, disclose, copy, print or rely on this
e-mail. If an addressing or transmission error has misdirected this
e-mail, kindly notify the author by replying to this e-mail or contacting
us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
Ayden Férdeline Statement of Interest <https://community.icann.org/display/gnsosoi/Ayden+Férdeline+SOI>
Ayden Férdeline Statement of Interest <https://community.icann.org/display/gnsosoi/Ayden+Férdeline+SOI>
A more compressed version of my email is, the Internet must be a safe and secure environment for commerce and communication, and we all have a role to play in keeping it this way. However, all security solutions must respect fundamental human rights, values and expectations. If you find the time to read my original message, I am happy to discuss it further with you off-list. - Ayden On Mon, Jul 4, 2016 1:07 PM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote: Nice work, Great mail. It seems I can’t compete with you on the time limitation that I have. So I would apologize that I will not be able to go through this, but as a member of this WG, I am sure it would be useful. The Chair, you have a lot of work to do and we will all keep you on your toes :-) Best wishes, -Vaibhav Aggarwal From: Ayden Férdeline < icann@ferdeline.com > Date: Monday, July 4, 2016 at 5:21 PM To: Vaibhav Aggarwal < va@bladebrains.com > Cc: Volker Greimann < vgreimann@key-systems.net >, < gnso-rds-pdp-wg@icann.org > Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements VA, hi- I apologise for getting your name wrong in my previous message. I appreciate that we have approached this issue from different perspectives, but I do not accept that security strategies must trump individual freedoms. In particular, I disagree with your suggestion that “security drives policy which drives business.” I would like to put forward that the opposite is true – red tape hinders business, it does not drive it. In my view, policy should be set only when there is an outcome that is either desired or should be prevented. If I take your example, that having an accurate directory of contact information for registrants is desirable from the perspective of maintaining law and order online, I would like to suggest that restricting one’s ability to register a domain name unless they provide verified personal data is a poor means of achieving your desired goal. It might well have significant collateral damage for, say, those blogging against repressive governments. I agree with you that the security of the Internet is a responsibility that we all share. We will all be secure only when we are protecting ourselves, our neighbours, the vulnerable, etc… So for this reason I have to say that I object to your characterisation of only those persons prepared to sacrifice their fundamental right to privacy as being “well-meaning and law-abiding citizens”. I refer you to this public comment by Karl Auerbach in 2006, where he noted that, “The Whois database for DNS names has already caused real and substantial harm. Every one of us has received spam and phone calls based on whois data. But the harm goes much deeper. It goes so deep that women have been stalked based on DNS whois data. It goes so deep that families who use the internet to communicate are forced by DNS whois to expose their names, their addresses, their phone numbers, their afilliations - not just of parents but also of their children - to anyone, including predators, 24x7x365.” These are people who I would classify as well-meaning and law-abiding citizens. A security ‘solution’ which does not foster confidence in the Internet, but causes more harm than good, is not something I would be comfortable supporting. Finally, I’m not sure what the “laws of the land” are which you refer to? We haven’t even agreed on whether data should be localised, distributed, federated… so we are jumping a head a little. I presume you are referring to national laws, and if so, I would like to add that I do not want ICANN to be involved in questions to do with jurisdiction, and certainly not until such time as global tensions around ensuring due process for all, and respecting human rights in online contexts, are resolved. I am imagining a scenario where we determine, say, we will have gated access for individuals (and I fully appreciate that we have yet to enter into deliberations on this front… this is simply an example). If a website’s owner is based, say, in Taiwan, their website is hosted on a server in Canada, the webhost is incorporated in Panama, their domain name registrar is in the Netherlands, and ICANN’s central repository of registration data is in the United States (if we went with a federated approach); what would happen if a request was received from law enforcement in China requesting the registrant’s personal data? Should it be fulfilled, even if there was reasonable suspicion that it would result in harm to the registrant? This may seem an extreme example but I suspect there will be overlapping if not conflicting territorial criteria somewhere along the way that is going to risk destroying the nature and benefits that the Internet, as a global network of networks, has brought about, and so we should steer well clear of any such discussions. So please. Let us avoid questions of jurisdiction, and not sacrifice our fundamental rights, freedoms and values in order to maintain ‘security’. I like the Benjamin Franklin quote that Volker ended his email with. It's very fitting. Best wishes, Ayden On Mon, Jul 4, 2016 12:13 PM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote: Ayden, 1. The Name is Vaibhav Aggarwal for your reference. 2. The Fostering responsibility is to inculcated at all levels. Crony capitalism cannot drive security – but global studies have demonstrated Security drives policy which drives businesses. Businesses always adapt, policy doesn't. 2a. Privacy or Data Security point is perfectly brought. Severe penalties should be built in onto businesses and legal liabilities be created in line with the laws of the land, for leaks in data. Any verified data is protected by a private and confidential clause in the service agreement with the customer. 3. Well meaning and Law Abiding Citizens always are up for easy forms of verifications. And Such data will be available in Studies globally in different countries, Diff. industries, diff. environments and situations and they are happy to accommodate; Lets deliberate in the time to come. This is a vast topic but specific, Mr. M.M.Oberoi (INDIAN POLICE SERVICE)– Cyber Security Head of Interpol Asia is at Singapore – I also recommend people like him can be roped in. I know that people from US agencies like the CIA and NSA and FBI Cyber Division, and the other countries will be more than willing to contribute to this, if need be. I have friends, will be happy to help. Regards, -VA From: Ayden Férdeline < icann@ferdeline.com > Date: Monday, July 4, 2016 at 4:19 PM To: Vaibhav Aggarwal < va@bladebrains.com > Cc: Volker Greimann < vgreimann@key-systems.net >, < gnso-rds-pdp-wg@icann.org > Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Catalyst, hi- I agree that we all have a responsibility to address Internet security issues. However, in doing so, I would like to put forward that we all have a responsibility to respect fundamental human rights and values, including the right to privacy. We will never be able to entirely eliminate the threats posed by bad actors. As you said, fake email addresses and burner phones are all possibilities today. If we put too many barriers in place to registering a domain name, we are not going to stop those who are registering domain names for malicious purposes. They will always find ways to get content online. We will hurt and inconvenience only well-meaning and law-abiding citizens who rely on domain names to express their ideas, to manage their micro enterprise, or to otherwise engage in lawful activities. In all that we do as a working group I would like us to foster confidence in the Internet and to protect opportunities online for economic and social prosperity. Best wishes, Ayden On Mon, Jul 4, 2016 10:49 AM, Catalyst-Vaibhav Aggarwal va@bladebrains.com wrote: The Responsibility is of the party who is driving profit or providing service. The Registrant is the party who is to be checked for his / her credentials to prevent misuse. The situation is alarming- this is evident of the data being published y various Registries or Governments from time to time related to Bogus Registrations, Misused Domain names cancelled or and Spam Originating Domain Names. A Stake Holder from Maccabee / Norton / Sentinel / MXBlackList / Avast etc such Engines can be referred to for such data collection for the use of consultations. And any such suggestion can easily be implemented with the Automation of the entire Verification process. For Eg. Gmail has a two Step Authentication - One on the Password and the other on the Phone Number of the User. To begin with, the phone is the Personal verified connection by the local authorities. A Burner Phone in the US may not be Digitally Authenticated, but the NSA in the US has a way to it. AUTOMATED. This can be elaborated as and when the case come up for hearing in the WG, in a formal setting. And if this is not done today due to extensive lobbying efforts by a particular section / Industry members, it will be done as a Mandate tomorrow. We might as well prepare today and keep provisions as the overhaul of the framework and the systems, is inevitable. This is a issue regaining the safety of me, my family, I don¹t think, I am or anybody will be willing to compromise. And the Lives being lost and the Resources being insufficient to tract these anti-social activities are being proven insufficient again and again, there is little contribution we can do to the safety of us. Sincerely, -VA On 7/4/16, 2:57 PM, "Volker Greimann" < gnso-rds-pdp-wg-bounces@icann.org on behalf of vgreimann@key-systems.net > wrote:
I disagree. The only party that should be responsible for maintaining
good data is the registrant. The responsibilities of registrars,
registries and proxy services should revolve only on the correct
maintenance of that data and on acting when informed about actual issues
with the whois data.
Best,
Volker
Am 30.06.2016 um 22:19 schrieb Mark Svancarek via gnso-rds-pdp-wg:
I think it's perfectly reasonable to expect accurate WhoIs data, proxy
services included, so long as contracts are enforced. That isn't the
case today as far as I can tell, but with ICANN under new management I
think we should hold ICANN, registries, registrars AND proxy providers
accountable to provide good data with penalties consistently enforced.
-----Original Message-----
From: gnso-rds-pdp-wg-bounces@icann.org
[ mailto:gnso-rds-pdp-wg-bounces@icann.org ] On Behalf Of Andrew Sullivan
Sent: Thursday, June 30, 2016 11:07 PM
To: gnso-rds-pdp-wg@icann.org
Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on
requirements
On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it
with: privacy proxy services can sit between the registrant and
registrar - Andrew's models didn't explicitly mention that. Keep
that in mind when we discuss what is collected, who its shared with,
and where its stored.
Well, yes, but from the point of view of the registration system the
registrant is actually the proxy service. The "real" registrant in
effect has an agreement with the proxy service that the proxy service
will abide by the "real" registrant's instructions. It's a matter of
contract whether that happens, of course -- the registrar simply can't
tell who the "real" registrant is.
I sort of alluded to this in my original remarks. This is also part of
the reason why I think the entire "accurate whois data" shuffle is such
an absurd waste of time. There is literally no way to prevent these
kinds of proxy registrations from happening, because the actual proxy
activity happens outside the registration context. One can of course
make them more expensive with increasingly baroque rules, but that's not
the same thing as somehow managing to make them disappear.
(Compare this with the "sublet" market for rent-controlled apartments
in some jurisdictions in order to see why this is the case.)
Best regards,
A
--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann
.org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40micro
soft.com%7cf38dec4589b048b7524e08d3a122326d%7c72f988bf86f141af91ab2d7cd01
1db47%7c1&sdata=S703VAg7xNmJKcfrG%2bwQcrANtef9QhGqILmSBfHfbNQ%3d
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns
per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact
us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay
updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom
it is addressed. Furthermore it is not permitted to publish any content
of this email. You must not use, disclose, copy, print or rely on this
e-mail. If an addressing or transmission error has misdirected this
e-mail, kindly notify the author by replying to this e-mail or contacting
us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg Ayden Férdeline Statement of Interest Ayden Férdeline Statement of Interest Ayden Férdeline Statement of Interest
To what extent do the recommendations of the Privacy & Proxy Services PDP recommendations affect this? For those who may not be aware, the recommendations are awaiting Board approval and the Board is waiting to act while it considers GAC advice; the GAC -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 4:07 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is. I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear. (Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.) 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
Sorry for clicking send to soon. I finished my message in a follow-up message. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: Saturday, July 02, 2016 5:14 PM To: Andrew Sullivan; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements To what extent do the recommendations of the Privacy & Proxy Services PDP recommendations affect this? For those who may not be aware, the recommendations are awaiting Board approval and the Board is waiting to act while it considers GAC advice; the GAC -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 4:07 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is. I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear. (Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.) 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
See the GAC Communique from Helsinki for their input on the Privacy & Proxy Services PDP recommendations. 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: Thursday, June 30, 2016 4:07 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements On Thu, Jun 30, 2016 at 07:51:58PM +0000, Mark Svancarek wrote:
One more comment regarding who collects the data and who they share it with: privacy proxy services can sit between the registrant and registrar - Andrew's models didn't explicitly mention that. Keep that in mind when we discuss what is collected, who its shared with, and where its stored.
Well, yes, but from the point of view of the registration system the registrant is actually the proxy service. The "real" registrant in effect has an agreement with the proxy service that the proxy service will abide by the "real" registrant's instructions. It's a matter of contract whether that happens, of course -- the registrar simply can't tell who the "real" registrant is. I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time. There is literally no way to prevent these kinds of proxy registrations from happening, because the actual proxy activity happens outside the registration context. One can of course make them more expensive with increasingly baroque rules, but that's not the same thing as somehow managing to make them disappear. (Compare this with the "sublet" market for rent-controlled apartments in some jurisdictions in order to see why this is the case.) 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
See the GAC Communique from Helsinki for their input on the Privacy & Proxy Services PDP recommendations.
When reading a GAC Communique, is it only me that automagically undoes their search-and-replace between "advises" and "demands" whilst desperately trying to filter out the subliminal message "you will obey" that's carefully hidden between each line ? I have no doubt that there will come a policy relating to P&P Services, but it can and will only ever be applicable to those directly provided by Registrars and Registries, and likely prove counter-productive in the long-run. There will never be an absolute connection between the Registrant and the beneficiary/operator/user of a domain, just like there is no absolute connection between who is currently inside a building and who is listed as owning the land it sits on.
I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time.
Partly because every group-with-an-agenda has a very different definition of what they think the word "accurate" means :) Rob -- Rob Golding rob.golding@astutium.com Astutium Ltd, Number One Poultry, London. EC2R 8JR * domains * hosting * vps * servers * cloud * backups *
+1 Sent from my mobile device. Typos regretted. On Jul 5, 2016, at 6:02 AM, Rob Golding <rob.golding@astutium.com> wrote:
See the GAC Communique from Helsinki for their input on the Privacy & Proxy Services PDP recommendations.
When reading a GAC Communique, is it only me that automagically undoes their search-and-replace between "advises" and "demands" whilst desperately trying to filter out the subliminal message "you will obey" that's carefully hidden between each line ?
I have no doubt that there will come a policy relating to P&P Services, but it can and will only ever be applicable to those directly provided by Registrars and Registries, and likely prove counter-productive in the long-run.
There will never be an absolute connection between the Registrant and the beneficiary/operator/user of a domain, just like there is no absolute connection between who is currently inside a building and who is listed as owning the land it sits on.
I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time.
Partly because every group-with-an-agenda has a very different definition of what they think the word "accurate" means :)
Rob -- Rob Golding rob.golding@astutium.com Astutium Ltd, Number One Poultry, London. EC2R 8JR
* domains * hosting * vps * servers * cloud * backups * _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I want to call attention to the following three paragraphs from the communique regarding Privacy & Proxy Services: "III. If the Board resolves to adopt the PPSAI recommendations, it should direct the Implementation Review Team (IRT) to ensure that the GAC concerns are effectively addressed in the implementation phase to the greatest extent possible. IV. GAC input and feedback should be sought out as necessary in developing a proposed implementation plan, including through participation of the Public Safety Working Group on the Implementation Review Team. V. If, in the course of the implementation discussions, policy issues emerge, they should be referred back to the GNSO for future deliberations in consultation with the GAC on potential enhancements to privacy and proxy service accreditation." To me it is a good sign that the GAC recognizes that the Board may adopt the PPSAI recommendations as is and, to the extent that the GAC recommendations can be dealt with during implementation, that is okay. Note that they say "to the greatest extent possible". Paragraph V then goes on to say exactly what should happen according to the Policy & Implementation recommendations that the Board approved. In my opinion, the GAC's statements in this part of the communique demonstrate that they are understanding and accepting their role and the role of the GNSO. That is a good sign. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Monday, July 04, 2016 8:33 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
See the GAC Communique from Helsinki for their input on the Privacy & Proxy Services PDP recommendations.
When reading a GAC Communique, is it only me that automagically undoes their search-and-replace between "advises" and "demands" whilst desperately trying to filter out the subliminal message "you will obey" that's carefully hidden between each line ? I have no doubt that there will come a policy relating to P&P Services, but it can and will only ever be applicable to those directly provided by Registrars and Registries, and likely prove counter-productive in the long-run. There will never be an absolute connection between the Registrant and the beneficiary/operator/user of a domain, just like there is no absolute connection between who is currently inside a building and who is listed as owning the land it sits on.
I sort of alluded to this in my original remarks. This is also part of the reason why I think the entire "accurate whois data" shuffle is such an absurd waste of time.
Partly because every group-with-an-agenda has a very different definition of what they think the word "accurate" means :) Rob -- Rob Golding rob.golding@astutium.com Astutium Ltd, Number One Poultry, London. EC2R 8JR * domains * hosting * vps * servers * cloud * backups * _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I personally have no problem accepting the fact that we are stuck with RDAP but I have decided that we can proceed with the work plan and charter direction as is and still accomplish what is needed. I suspect that once we do get to the point of protocol decision our main task will be to identify what tweaks may be needed to RDAP. But until we identify the requirements and then associated policies to fulfill the requirements, it will not be possible to define any such tweaks. 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: Thursday, June 30, 2016 1:57 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements On Thu, Jun 30, 2016 at 08:20:50AM +0000, Gomes, Chuck wrote:
I would be happy to be wrong about the need for a charter change so we will explore that further. If the main thing we are talking about is Federated v. Distributed, then I don't think a charter change would be needed. Am I correct that is the main issue or is there more to what Andrew is suggesting?
Well, there may be more or less. If you look at the model diagrams I sent, you'll notice that they all include the registration side of this as well. Some of our conversations have been framed as though there is some _other_ place where the registration data gets collected, but there isn't. It's all collected through registrars and registries. This is part of why I was trying to suggest that, "What data is collected?" is not one question, but many. Only in Model I -- which hasn't existed for years -- do we have a system in which you can meaningfully ask, "What is collected?" without also asking, "Who collects it?" In Model II, registrars (and only registrars) collect all the data that comes from a registrant. They pass _some_ data along to the registries. In Model IV, the same approach can be used. In Model III, registrars collect all the data, but they also pass almost all of it along to registries. So, three parties (including the registrant) have the data, and one of those parties (the registry) has no direct agreement with the originator of the data. Model IV can also use this approach. Model IV has the additional property that, depending on the authentication of who asks the question, the protocol can provide more or less data in the response. It can do this regardless of who collected the data. Therefore, the issue here is really two dimensional: which parties have any given set of data at any time, and how much of that data will it disclose. As Jay Daley said in the meeting the other day, the second of those dimensions can be answered in steps: "assume completely unauthenticated access; how much is revealed?", and so on. The answer to those issues is _unrelated_ to the first dimension if you pick the right protocol to start with, because you can specify from the beginning that any protocol that could possibly meet our needs must work in a distributed fashion. In that case, you're sort of stuck with RDAP, or with inventing one yourself, because our experience with whois (the protocol, port 43 and webby things built atop it) is that it doesn't work that reliably. Does this answer your question? 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
Hi Stephanie, My recollection of the EWG work is very different from yours. We were given the mandate to reimagine the WHOIS and I do not remember anything being out of scope. The WHOIS review team was definitely bound by AOC to limit our review and many things were out of scope which is why I found the work on the EWG refreshing. In fact, Steve Crocker frequently reminded us not to limit our thinking to the existing structures and requirements but after examining many use cases we found that there was good reason to require the collection of much of the same information. I do agree that this PDP WG should go through a similar process of reviewing and deliberating and come to their own conclusions. Best, Susan Kawaguchi Domain Name Manager Facebook Legal Dept. From: <gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> Date: Wednesday, June 29, 2016 at 10:58 PM To: "gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements". Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote: Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. " It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time. "While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model." I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Drds-2Dpdp-2Dwg&d=CwMD-g&c=5VD0RTtNlTh3ycd41b3MUw&r=gvEx8xF7ynrYQ7wShqEr-w&m=tyblCirrtbvSj97cc17NFyaD6X219nVl0GXQWlFWkXM&s=M8CMTX36mixkDN5jXQOJi6XTzgmXQNnNxk9gJ-vWByY&e=> _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Drds-2Dpdp-2Dwg&d=CwMD-g&c=5VD0RTtNlTh3ycd41b3MUw&r=gvEx8xF7ynrYQ7wShqEr-w&m=tyblCirrtbvSj97cc17NFyaD6X219nVl0GXQWlFWkXM&s=M8CMTX36mixkDN5jXQOJi6XTzgmXQNnNxk9gJ-vWByY&e=>
Sadly, Susan, this is one of the problems with not having transcripts of our week long meetings. Neither one of us can check a transcript to see if we were somehow operating in parallel universes. Having been around ICANN for some time, you would have a much better understanding than I about what was possible. I have a distinct memory of Michele informing me I could not see the draft 2013 RAA nor alter the outcomes, as the announcement was about to happen. I cannot quote anyone else really without seeking their consent. As for thick/thin WHOIS, it took me a while to figure out what all these systems meant in terms of data flow and rights enforcement. If you are telling me that I could have showed up in Buenos Aires and said, Ok guys, we have to throw out all thick registries, then clearly I missed an opportunity. Chalk that one up to being under-resourced on the civil society side...mea culpa. Best Stephanie On 2016-06-30 5:25, Susan Kawaguchi wrote:
Hi Stephanie,
My recollection of the EWG work is very different from yours. We were given the mandate to reimagine the WHOIS and I do not remember anything being out of scope. The WHOIS review team was definitely bound by AOC to limit our review and many things were out of scope which is why I found the work on the EWG refreshing. In fact, Steve Crocker frequently reminded us not to limit our thinking to the existing structures and requirements but after examining many use cases we found that there was good reason to require the collection of much of the same information.
I do agree that this PDP WG should go through a similar process of reviewing and deliberating and come to their own conclusions.
Best, Susan Kawaguchi Domain Name Manager Facebook Legal Dept.
From: <gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca <mailto:stephanie.perrin@mail.utoronto.ca>> Date: Wednesday, June 29, 2016 at 10:58 PM To: "gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry.....
However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach.
In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally).
I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements".
Stephanie Perrin
On 2016-06-29 21:04, Gomes, Chuck wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
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: Friday, June 24, 2016 10:04 PM To:gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-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.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I believe you could have advocated to throw out all thick registries and I remember a discussion very similar to that. We debated if we could limit the information displayed to what is currently in the Thin Whois and the data the EWG recommended to provide publicly outside the gate is less than what is currently in the Thin Whois. But we also recommended to allow collection of all the current data elements and added some. The debate was really over who could access the data. I agree without transcripts this is only my recollection. And I completely agree we are all under-resourced. ICANN is overwhelming at times. Susan Kawaguchi Domain Name Manager Facebook Legal Dept. From: Stephanie Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> Date: Thursday, June 30, 2016 at 3:45 AM To: Susan kawaguchi <susank@fb.com<mailto:susank@fb.com>>, "gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Sadly, Susan, this is one of the problems with not having transcripts of our week long meetings. Neither one of us can check a transcript to see if we were somehow operating in parallel universes. Having been around ICANN for some time, you would have a much better understanding than I about what was possible. I have a distinct memory of Michele informing me I could not see the draft 2013 RAA nor alter the outcomes, as the announcement was about to happen. I cannot quote anyone else really without seeking their consent. As for thick/thin WHOIS, it took me a while to figure out what all these systems meant in terms of data flow and rights enforcement. If you are telling me that I could have showed up in Buenos Aires and said, Ok guys, we have to throw out all thick registries, then clearly I missed an opportunity. Chalk that one up to being under-resourced on the civil society side...mea culpa. Best Stephanie On 2016-06-30 5:25, Susan Kawaguchi wrote: Hi Stephanie, My recollection of the EWG work is very different from yours. We were given the mandate to reimagine the WHOIS and I do not remember anything being out of scope. The WHOIS review team was definitely bound by AOC to limit our review and many things were out of scope which is why I found the work on the EWG refreshing. In fact, Steve Crocker frequently reminded us not to limit our thinking to the existing structures and requirements but after examining many use cases we found that there was good reason to require the collection of much of the same information. I do agree that this PDP WG should go through a similar process of reviewing and deliberating and come to their own conclusions. Best, Susan Kawaguchi Domain Name Manager Facebook Legal Dept. From: <<mailto:gnso-rds-pdp-wg-bounces@icann.org>gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Stephanie Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> Date: Wednesday, June 29, 2016 at 10:58 PM To: "<mailto:gnso-rds-pdp-wg@icann.org>gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements I have not responded either to Andrew's excellent post. As a member of the EWG, representing the privacy rights constituency, I must say that I was faced with an embarrassment of riches on that group in terms of things to argue about. Fellow EWG members will likely be willing to back me up that I gave it my best shot in terms of pushback. The central model was not one I spent much energy on, being non-technical and thus requiring backup support which was difficult to arrange given our confidential operations. Meeting number 2 I gave up on that one. IN particular, since I did not understand the rationale that was driving the thick vs thin work that was ongoing and out of scope for our discussions (done deal), the actual mechanism that would drive us to a thin model that seemed to me desirable from a privacy perspective appeared to be out of reach. Similarly, since the 2013 RAA was out of scope and contained masses of embedded policy decisions that had never gone through a proper pdp process that I could find, tiered access using RDAP appeared to be the only hope. Having worked on authentication issues for a long time, I have some notion about the cost and complexity issues for what I would want under this model, which is why I will be harping on costs and who pays (file under fair warning) because I don't like working on something for five years only to be told at the end of it that Oops, we can't afford this, who is going to pay? So sorry..... However, we are supposed to be the group that is looking at the issue de novo. We are supposed to be paying attention to the SSAC and Article 29 documents which, coincidentally both tell us to "figure out what the purpose of collecting, using, and storing registration data is and then we will tell you how to build and what to build" (loosely translated). "What to build" is a very important trio of words for those of us who are policy oriented and not technology oriented, because the concept of what we are doing creates a gestalt that influences policy choices, mostly negatively in my view. If I may give another example in the privacy field, we still talk about "video surveillance" to describe our security camera technologies, summoning up images of the decades old video cameras and tapes we used to have. This prevents deeper questioning of data flows and ancillary inputs, making the privacy choices seem deceptively simple. This is why I am so enthused about Andrew's post, it helps me understand how to go back to a de novo approach. In my view, the thorough debates of the EWG on various issues should have been done in public. The presentations we gave were cheery but lean on detail and choices, in my view. Furthermore, as the lone privacy representative, I could have used a Caspar Bowden or a Ross Anderson or a Kyle Rannenberg or an Ian Goldberg in my corner, to name just a couple of the folks I yearned to consult but could not (and not to mention Andrew Sullivan whom I do not know personally). I would be happy to introduce the Charter change proposal at Council, once we have figured out what the desirable change might be. Let us please face the reality that we do not have the number of multidisciplinary lateral thinkers in our PDP that it would take to figure this all out, and not be embarrassed about going back and forth on the Charter. No aspersions being cast on the Charter drafting group, or our collective failure to comment beyond putting markers in for our own siloed issues, and our own siloed understanding of "requirements". Stephanie Perrin On 2016-06-29 21:04, Gomes, Chuck wrote: Andrew, I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns: 1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind. 2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below. " It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time. "While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model." I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation. Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements Dear colleagues, Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky. I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long. Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed. The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question. Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery. Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on. Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?) The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans. The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed. People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data. The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill. It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway. Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive. 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Drds-2Dpdp-2Dwg&d=CwMD-g&c=5VD0RTtNlTh3ycd41b3MUw&r=gvEx8xF7ynrYQ7wShqEr-w&m=tyblCirrtbvSj97cc17NFyaD6X219nVl0GXQWlFWkXM&s=M8CMTX36mixkDN5jXQOJi6XTzgmXQNnNxk9gJ-vWByY&e=> _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Drds-2Dpdp-2Dwg&d=CwMD-g&c=5VD0RTtNlTh3ycd41b3MUw&r=gvEx8xF7ynrYQ7wShqEr-w&m=tyblCirrtbvSj97cc17NFyaD6X219nVl0GXQWlFWkXM&s=M8CMTX36mixkDN5jXQOJi6XTzgmXQNnNxk9gJ-vWByY&e=>
Coming to this conversation late but as a member of the EWG, my recollection is we took seriously the stated objective to chart a next generation RDDS unfettered by existing WHOIS constraints. To that end, I was one of those who insisted and the group accepted and grappled with the basic question; was there a need for a RDDS and, to what purpose. For those mindful of the ALAC perspective, this would not be new; the ALAC is on record from as early as 2009 insisting that for policy development purposes, the need and purpose for a RDDS ought, by reason and judgment, to be the first declarative act of any policy development process. You would have seen a reprise of that principle here. We were acutely aware that some principles we espoused are contrary by nature - privacy vs. security, transparency vs. confidentiality and so on - and that balancing the scale between contention sets of principles was not going to be for the faint-hearted. Some time ago I used a metaphor to describe what was achieved; we set out to design and build a sleek racehorse but with the contentions, likely ended up with a two-humped camel. Naturally, some took umbrage on behalf of camels. My recollection - and the record will show - the EWG spent an inordinate amount of time looking at use cases, the thinking being it would allow extraction of a set of principles grounded in facts on the ground. Yes, some of us had concerns about this as starting point to get to principles; use cases conflated both appropriate and alleged inappropriate uses, highlighting some of the alleged noisome abuses. Some of us soldiered on , embracing the idea that a comprehensive problem statement provides the best indicator to an improved model. This is why the gripes of current stakeholders, the expert opinions and deeper knowledge of what ails the current system took so much time of our deliberations. The mitigation model that emerged is fairly easy to script. I cannot recall any contest to the idea that data accuracy is sine qua non for any RDDS. Yes, we are very much aware of the distributed nature of current WHOIS and even examined a model so configured in the solution set we discussed. Again, balancing the contentions, the centralized database offers certain advantages - and these are listed in details - at least for standard enforcement, query and access control. The concept of a minimum set of RDDS data elements for global unfettered display stems from privacy concerns and, coincidentally, a nod to the 'thin' model. Gated access in the model addressed the concerns from the perspective of a broader set of business reasons for RDDS access, privacy and the evaluation of and better knowledge of purposeful use. I could give a lot more examples that underscore a different narrative. Not just because I spent almost 2 years of my life working this on a truly voluntary basis - I do not make a living from the ecosystem and my day job has no connection to it - but for the fact I sincerely believe that what was achieved was remarkable in and of itself. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 *Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Wed, Jun 29, 2016 at 8:04 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
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: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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
One point here, and it is not a big one. I don't accept that accuracy is a sine qua non (see para 5). Contactability is, I think it ends there. Excessive focus on accuracy of data, when that data is not necessary any more is a cost and consumer burden, not to mention an invasion of privacy. (eg. if I have changed my mastercard number but my registration is paid for two years, no need to change it in the record) I did not comment earlier on Volker's remark that responsibility for accuracy of data rests with the registrant, but I agree whole heartedly. How can it be otherwise? Some parties would like to authenticate every individual and every transaction on the INternet, and see the registrars as the entry point and therefore the logical ones to bear this (enormous) burden. This is unnecessary and will price domains out of the range of individuals who can benefit most from their own place on the Internet, in my view. It would hardly be appropriate for the policy person to point out that in any authentication scheme, identifying the individual in the first place (prior to tying that individual to some identifier) is a big, costly and complex matter that has slowed down many an implementation of secure transactions. We need to limit our attempts to identify individuals to only what is necessary. Stephanie Perrin PS I wish I had taken better notes on the whole thick/thin whois issue during EWG. Since it took me a good while to figure out how this thing had developed in the first place, (and many thanks to my EWG colleagues who patiently explained it to me over and over again) I may have missed an invitation to throw it out and discuss it again from scratch.....but I doubt it. Anyway, we were already talking about tiered access by then and different configurations of the model which would make it much less relevant. On 2016-07-04 12:22, Carlton Samuels wrote:
Coming to this conversation late but as a member of the EWG, my recollection is we took seriously the stated objective to chart a next generation RDDS unfettered by existing WHOIS constraints.
To that end, I was one of those who insisted and the group accepted and grappled with the basic question; was there a need for a RDDS and, to what purpose. For those mindful of the ALAC perspective, this would not be new; the ALAC is on record from as early as 2009 insisting that for policy development purposes, the need and purpose for a RDDS ought, by reason and judgment, to be the first declarative act of any policy development process. You would have seen a reprise of that principle here.
We were acutely aware that some principles we espoused are contrary by nature - privacy vs. security, transparency vs. confidentiality and so on - and that balancing the scale between contention sets of principles was not going to be for the faint-hearted. Some time ago I used a metaphor to describe what was achieved; we set out to design and build a sleek racehorse but with the contentions, likely ended up with a two-humped camel. Naturally, some took umbrage on behalf of camels.
My recollection - and the record will show - the EWG spent an inordinate amount of time looking at use cases, the thinking being it would allow extraction of a set of principles grounded in facts on the ground. Yes, some of us had concerns about this as starting point to get to principles; use cases conflated both appropriate and alleged inappropriate uses, highlighting some of the alleged noisome abuses. Some of us soldiered on , embracing the idea that a comprehensive problem statement provides the best indicator to an improved model. This is why the gripes of current stakeholders, the expert opinions and deeper knowledge of what ails the current system took so much time of our deliberations. The mitigation model that emerged is fairly easy to script. I cannot recall any contest to the idea that data accuracy is sine qua non for any RDDS. Yes, we are very much aware of the distributed nature of current WHOIS and even examined a model so configured in the solution set we discussed. Again, balancing the contentions, the centralized database offers certain advantages - and these are listed in details - at least for standard enforcement, query and access control. The concept of a minimum set of RDDS data elements for global unfettered display stems from privacy concerns and, coincidentally, a nod to the 'thin' model. Gated access in the model addressed the concerns from the perspective of a broader set of business reasons for RDDS access, privacy and the evaluation of and better knowledge of purposeful use.
I could give a lot more examples that underscore a different narrative. Not just because I spent almost 2 years of my life working this on a truly voluntary basis - I do not make a living from the ecosystem and my day job has no connection to it - but for the fact I sincerely believe that what was achieved was remarkable in and of itself.
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 /Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Jun 29, 2016 at 8:04 PM, Gomes, Chuck <cgomes@verisign.com <mailto:cgomes@verisign.com>> wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
Chuck
-----Original Message----- 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 Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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 https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Ultimately, everyone accessing the internet can be identified at the level of the access provider. The domain name is probably the most useless point to identify a user, as the domain name registrant may not even have to do anything with a specific use. Best, Volker Am 04.07.2016 um 19:25 schrieb Stephanie Perrin:
One point here, and it is not a big one. I don't accept that accuracy is a sine qua non (see para 5). Contactability is, I think it ends there. Excessive focus on accuracy of data, when that data is not necessary any more is a cost and consumer burden, not to mention an invasion of privacy. (eg. if I have changed my mastercard number but my registration is paid for two years, no need to change it in the record)
I did not comment earlier on Volker's remark that responsibility for accuracy of data rests with the registrant, but I agree whole heartedly. How can it be otherwise? Some parties would like to authenticate every individual and every transaction on the INternet, and see the registrars as the entry point and therefore the logical ones to bear this (enormous) burden. This is unnecessary and will price domains out of the range of individuals who can benefit most from their own place on the Internet, in my view. It would hardly be appropriate for the policy person to point out that in any authentication scheme, identifying the individual in the first place (prior to tying that individual to some identifier) is a big, costly and complex matter that has slowed down many an implementation of secure transactions. We need to limit our attempts to identify individuals to only what is necessary.
Stephanie Perrin PS I wish I had taken better notes on the whole thick/thin whois issue during EWG. Since it took me a good while to figure out how this thing had developed in the first place, (and many thanks to my EWG colleagues who patiently explained it to me over and over again) I may have missed an invitation to throw it out and discuss it again from scratch.....but I doubt it. Anyway, we were already talking about tiered access by then and different configurations of the model which would make it much less relevant. On 2016-07-04 12:22, Carlton Samuels wrote:
Coming to this conversation late but as a member of the EWG, my recollection is we took seriously the stated objective to chart a next generation RDDS unfettered by existing WHOIS constraints.
To that end, I was one of those who insisted and the group accepted and grappled with the basic question; was there a need for a RDDS and, to what purpose. For those mindful of the ALAC perspective, this would not be new; the ALAC is on record from as early as 2009 insisting that for policy development purposes, the need and purpose for a RDDS ought, by reason and judgment, to be the first declarative act of any policy development process. You would have seen a reprise of that principle here.
We were acutely aware that some principles we espoused are contrary by nature - privacy vs. security, transparency vs. confidentiality and so on - and that balancing the scale between contention sets of principles was not going to be for the faint-hearted. Some time ago I used a metaphor to describe what was achieved; we set out to design and build a sleek racehorse but with the contentions, likely ended up with a two-humped camel. Naturally, some took umbrage on behalf of camels.
My recollection - and the record will show - the EWG spent an inordinate amount of time looking at use cases, the thinking being it would allow extraction of a set of principles grounded in facts on the ground. Yes, some of us had concerns about this as starting point to get to principles; use cases conflated both appropriate and alleged inappropriate uses, highlighting some of the alleged noisome abuses. Some of us soldiered on , embracing the idea that a comprehensive problem statement provides the best indicator to an improved model. This is why the gripes of current stakeholders, the expert opinions and deeper knowledge of what ails the current system took so much time of our deliberations. The mitigation model that emerged is fairly easy to script. I cannot recall any contest to the idea that data accuracy is sine qua non for any RDDS. Yes, we are very much aware of the distributed nature of current WHOIS and even examined a model so configured in the solution set we discussed. Again, balancing the contentions, the centralized database offers certain advantages - and these are listed in details - at least for standard enforcement, query and access control. The concept of a minimum set of RDDS data elements for global unfettered display stems from privacy concerns and, coincidentally, a nod to the 'thin' model. Gated access in the model addressed the concerns from the perspective of a broader set of business reasons for RDDS access, privacy and the evaluation of and better knowledge of purposeful use.
I could give a lot more examples that underscore a different narrative. Not just because I spent almost 2 years of my life working this on a truly voluntary basis - I do not make a living from the ecosystem and my day job has no connection to it - but for the fact I sincerely believe that what was achieved was remarkable in and of itself.
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 /Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Jun 29, 2016 at 8:04 PM, Gomes, Chuck <cgomes@verisign.com <mailto:cgomes@verisign.com>> wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
Chuck
-----Original Message----- 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 Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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 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.
As someone who uses this information to put people in prison, it is not as useless as you may think it is even when it's "incorrect", or for that matter "whois privacy protected". On 7/5/2016 4:08 AM, Volker Greimann wrote:
Ultimately, everyone accessing the internet can be identified at the level of the access provider. The domain name is probably the most useless point to identify a user, as the domain name registrant may not even have to do anything with a specific use.
Best,
Volker
Am 04.07.2016 um 19:25 schrieb Stephanie Perrin:
One point here, and it is not a big one. I don't accept that accuracy is a sine qua non (see para 5). Contactability is, I think it ends there. Excessive focus on accuracy of data, when that data is not necessary any more is a cost and consumer burden, not to mention an invasion of privacy. (eg. if I have changed my mastercard number but my registration is paid for two years, no need to change it in the record)
I did not comment earlier on Volker's remark that responsibility for accuracy of data rests with the registrant, but I agree whole heartedly. How can it be otherwise? Some parties would like to authenticate every individual and every transaction on the INternet, and see the registrars as the entry point and therefore the logical ones to bear this (enormous) burden. This is unnecessary and will price domains out of the range of individuals who can benefit most from their own place on the Internet, in my view. It would hardly be appropriate for the policy person to point out that in any authentication scheme, identifying the individual in the first place (prior to tying that individual to some identifier) is a big, costly and complex matter that has slowed down many an implementation of secure transactions. We need to limit our attempts to identify individuals to only what is necessary.
Stephanie Perrin PS I wish I had taken better notes on the whole thick/thin whois issue during EWG. Since it took me a good while to figure out how this thing had developed in the first place, (and many thanks to my EWG colleagues who patiently explained it to me over and over again) I may have missed an invitation to throw it out and discuss it again from scratch.....but I doubt it. Anyway, we were already talking about tiered access by then and different configurations of the model which would make it much less relevant. On 2016-07-04 12:22, Carlton Samuels wrote:
Coming to this conversation late but as a member of the EWG, my recollection is we took seriously the stated objective to chart a next generation RDDS unfettered by existing WHOIS constraints.
To that end, I was one of those who insisted and the group accepted and grappled with the basic question; was there a need for a RDDS and, to what purpose. For those mindful of the ALAC perspective, this would not be new; the ALAC is on record from as early as 2009 insisting that for policy development purposes, the need and purpose for a RDDS ought, by reason and judgment, to be the first declarative act of any policy development process. You would have seen a reprise of that principle here.
We were acutely aware that some principles we espoused are contrary by nature - privacy vs. security, transparency vs. confidentiality and so on - and that balancing the scale between contention sets of principles was not going to be for the faint-hearted. Some time ago I used a metaphor to describe what was achieved; we set out to design and build a sleek racehorse but with the contentions, likely ended up with a two-humped camel. Naturally, some took umbrage on behalf of camels.
My recollection - and the record will show - the EWG spent an inordinate amount of time looking at use cases, the thinking being it would allow extraction of a set of principles grounded in facts on the ground. Yes, some of us had concerns about this as starting point to get to principles; use cases conflated both appropriate and alleged inappropriate uses, highlighting some of the alleged noisome abuses. Some of us soldiered on , embracing the idea that a comprehensive problem statement provides the best indicator to an improved model. This is why the gripes of current stakeholders, the expert opinions and deeper knowledge of what ails the current system took so much time of our deliberations. The mitigation model that emerged is fairly easy to script. I cannot recall any contest to the idea that data accuracy is sine qua non for any RDDS. Yes, we are very much aware of the distributed nature of current WHOIS and even examined a model so configured in the solution set we discussed. Again, balancing the contentions, the centralized database offers certain advantages - and these are listed in details - at least for standard enforcement, query and access control. The concept of a minimum set of RDDS data elements for global unfettered display stems from privacy concerns and, coincidentally, a nod to the 'thin' model. Gated access in the model addressed the concerns from the perspective of a broader set of business reasons for RDDS access, privacy and the evaluation of and better knowledge of purposeful use.
I could give a lot more examples that underscore a different narrative. Not just because I spent almost 2 years of my life working this on a truly voluntary basis - I do not make a living from the ecosystem and my day job has no connection to it - but for the fact I sincerely believe that what was achieved was remarkable in and of itself.
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 /Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Jun 29, 2016 at 8:04 PM, Gomes, Chuck <cgomes@verisign.com <mailto:cgomes@verisign.com>> wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
Chuck
-----Original Message----- 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 Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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 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
Hey John, is it still helpful when the problem exists on a subdomain, a forum post, hacked sites, etc, i.e. all circumstances where the registrant is not the (only) user of the domain or only a service provider himself? In these cases, while you may need to be able to contact the registrant, knowing who he is is not really necessary to resolve the issue, correct? Best, Volker Am 05.07.2016 um 17:22 schrieb John Bambenek via gnso-rds-pdp-wg:
As someone who uses this information to put people in prison, it is not as useless as you may think it is even when it's "incorrect", or for that matter "whois privacy protected".
On 7/5/2016 4:08 AM, Volker Greimann wrote:
Ultimately, everyone accessing the internet can be identified at the level of the access provider. The domain name is probably the most useless point to identify a user, as the domain name registrant may not even have to do anything with a specific use.
Best,
Volker
Am 04.07.2016 um 19:25 schrieb Stephanie Perrin:
One point here, and it is not a big one. I don't accept that accuracy is a sine qua non (see para 5). Contactability is, I think it ends there. Excessive focus on accuracy of data, when that data is not necessary any more is a cost and consumer burden, not to mention an invasion of privacy. (eg. if I have changed my mastercard number but my registration is paid for two years, no need to change it in the record)
I did not comment earlier on Volker's remark that responsibility for accuracy of data rests with the registrant, but I agree whole heartedly. How can it be otherwise? Some parties would like to authenticate every individual and every transaction on the INternet, and see the registrars as the entry point and therefore the logical ones to bear this (enormous) burden. This is unnecessary and will price domains out of the range of individuals who can benefit most from their own place on the Internet, in my view. It would hardly be appropriate for the policy person to point out that in any authentication scheme, identifying the individual in the first place (prior to tying that individual to some identifier) is a big, costly and complex matter that has slowed down many an implementation of secure transactions. We need to limit our attempts to identify individuals to only what is necessary.
Stephanie Perrin PS I wish I had taken better notes on the whole thick/thin whois issue during EWG. Since it took me a good while to figure out how this thing had developed in the first place, (and many thanks to my EWG colleagues who patiently explained it to me over and over again) I may have missed an invitation to throw it out and discuss it again from scratch.....but I doubt it. Anyway, we were already talking about tiered access by then and different configurations of the model which would make it much less relevant. On 2016-07-04 12:22, Carlton Samuels wrote:
Coming to this conversation late but as a member of the EWG, my recollection is we took seriously the stated objective to chart a next generation RDDS unfettered by existing WHOIS constraints.
To that end, I was one of those who insisted and the group accepted and grappled with the basic question; was there a need for a RDDS and, to what purpose. For those mindful of the ALAC perspective, this would not be new; the ALAC is on record from as early as 2009 insisting that for policy development purposes, the need and purpose for a RDDS ought, by reason and judgment, to be the first declarative act of any policy development process. You would have seen a reprise of that principle here.
We were acutely aware that some principles we espoused are contrary by nature - privacy vs. security, transparency vs. confidentiality and so on - and that balancing the scale between contention sets of principles was not going to be for the faint-hearted. Some time ago I used a metaphor to describe what was achieved; we set out to design and build a sleek racehorse but with the contentions, likely ended up with a two-humped camel. Naturally, some took umbrage on behalf of camels.
My recollection - and the record will show - the EWG spent an inordinate amount of time looking at use cases, the thinking being it would allow extraction of a set of principles grounded in facts on the ground. Yes, some of us had concerns about this as starting point to get to principles; use cases conflated both appropriate and alleged inappropriate uses, highlighting some of the alleged noisome abuses. Some of us soldiered on , embracing the idea that a comprehensive problem statement provides the best indicator to an improved model. This is why the gripes of current stakeholders, the expert opinions and deeper knowledge of what ails the current system took so much time of our deliberations. The mitigation model that emerged is fairly easy to script. I cannot recall any contest to the idea that data accuracy is sine qua non for any RDDS. Yes, we are very much aware of the distributed nature of current WHOIS and even examined a model so configured in the solution set we discussed. Again, balancing the contentions, the centralized database offers certain advantages - and these are listed in details - at least for standard enforcement, query and access control. The concept of a minimum set of RDDS data elements for global unfettered display stems from privacy concerns and, coincidentally, a nod to the 'thin' model. Gated access in the model addressed the concerns from the perspective of a broader set of business reasons for RDDS access, privacy and the evaluation of and better knowledge of purposeful use.
I could give a lot more examples that underscore a different narrative. Not just because I spent almost 2 years of my life working this on a truly voluntary basis - I do not make a living from the ecosystem and my day job has no connection to it - but for the fact I sincerely believe that what was achieved was remarkable in and of itself.
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 /Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Jun 29, 2016 at 8:04 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
Chuck
-----Original Message----- 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 Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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 https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email:vgreimann@key-systems.net
Web:www.key-systems.net /www.RRPproxy.net www.domaindiscount24.com /www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email:vgreimann@key-systems.net
Web:www.key-systems.net /www.RRPproxy.net www.domaindiscount24.com /www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- 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.
As a general rule, I only use the information when the domain owner is also the criminal operator or a direct "service provider". For subdomains, say, for instance, dynamic DNS, it's another ball of wax. That being said, the more often subdomains are used for criminality, the more often security vendors use a heavy hand and just block the whole thing. That's the biggest reason new TLDs are often blacklisted or have low reputations for at least the first year, the biggest purchaser of domains under a new TLD are phishers. So short answer, unless domain owner = part of criminal operation, I usually don't pay attention unless some correlation can be drawn over a large number of discrete incidents. Rarely do I contact domain registrants directly. More often then not that just exposes me and my interests to the criminals in question and the risks outweigh the rewards. j On 7/5/2016 10:29 AM, Volker Greimann wrote:
Hey John,
is it still helpful when the problem exists on a subdomain, a forum post, hacked sites, etc, i.e. all circumstances where the registrant is not the (only) user of the domain or only a service provider himself? In these cases, while you may need to be able to contact the registrant, knowing who he is is not really necessary to resolve the issue, correct?
Best,
Volker
Am 05.07.2016 um 17:22 schrieb John Bambenek via gnso-rds-pdp-wg:
As someone who uses this information to put people in prison, it is not as useless as you may think it is even when it's "incorrect", or for that matter "whois privacy protected".
On 7/5/2016 4:08 AM, Volker Greimann wrote:
Ultimately, everyone accessing the internet can be identified at the level of the access provider. The domain name is probably the most useless point to identify a user, as the domain name registrant may not even have to do anything with a specific use.
Best,
Volker
Am 04.07.2016 um 19:25 schrieb Stephanie Perrin:
One point here, and it is not a big one. I don't accept that accuracy is a sine qua non (see para 5). Contactability is, I think it ends there. Excessive focus on accuracy of data, when that data is not necessary any more is a cost and consumer burden, not to mention an invasion of privacy. (eg. if I have changed my mastercard number but my registration is paid for two years, no need to change it in the record)
I did not comment earlier on Volker's remark that responsibility for accuracy of data rests with the registrant, but I agree whole heartedly. How can it be otherwise? Some parties would like to authenticate every individual and every transaction on the INternet, and see the registrars as the entry point and therefore the logical ones to bear this (enormous) burden. This is unnecessary and will price domains out of the range of individuals who can benefit most from their own place on the Internet, in my view. It would hardly be appropriate for the policy person to point out that in any authentication scheme, identifying the individual in the first place (prior to tying that individual to some identifier) is a big, costly and complex matter that has slowed down many an implementation of secure transactions. We need to limit our attempts to identify individuals to only what is necessary.
Stephanie Perrin PS I wish I had taken better notes on the whole thick/thin whois issue during EWG. Since it took me a good while to figure out how this thing had developed in the first place, (and many thanks to my EWG colleagues who patiently explained it to me over and over again) I may have missed an invitation to throw it out and discuss it again from scratch.....but I doubt it. Anyway, we were already talking about tiered access by then and different configurations of the model which would make it much less relevant. On 2016-07-04 12:22, Carlton Samuels wrote:
Coming to this conversation late but as a member of the EWG, my recollection is we took seriously the stated objective to chart a next generation RDDS unfettered by existing WHOIS constraints.
To that end, I was one of those who insisted and the group accepted and grappled with the basic question; was there a need for a RDDS and, to what purpose. For those mindful of the ALAC perspective, this would not be new; the ALAC is on record from as early as 2009 insisting that for policy development purposes, the need and purpose for a RDDS ought, by reason and judgment, to be the first declarative act of any policy development process. You would have seen a reprise of that principle here.
We were acutely aware that some principles we espoused are contrary by nature - privacy vs. security, transparency vs. confidentiality and so on - and that balancing the scale between contention sets of principles was not going to be for the faint-hearted. Some time ago I used a metaphor to describe what was achieved; we set out to design and build a sleek racehorse but with the contentions, likely ended up with a two-humped camel. Naturally, some took umbrage on behalf of camels.
My recollection - and the record will show - the EWG spent an inordinate amount of time looking at use cases, the thinking being it would allow extraction of a set of principles grounded in facts on the ground. Yes, some of us had concerns about this as starting point to get to principles; use cases conflated both appropriate and alleged inappropriate uses, highlighting some of the alleged noisome abuses. Some of us soldiered on , embracing the idea that a comprehensive problem statement provides the best indicator to an improved model. This is why the gripes of current stakeholders, the expert opinions and deeper knowledge of what ails the current system took so much time of our deliberations. The mitigation model that emerged is fairly easy to script. I cannot recall any contest to the idea that data accuracy is sine qua non for any RDDS. Yes, we are very much aware of the distributed nature of current WHOIS and even examined a model so configured in the solution set we discussed. Again, balancing the contentions, the centralized database offers certain advantages - and these are listed in details - at least for standard enforcement, query and access control. The concept of a minimum set of RDDS data elements for global unfettered display stems from privacy concerns and, coincidentally, a nod to the 'thin' model. Gated access in the model addressed the concerns from the perspective of a broader set of business reasons for RDDS access, privacy and the evaluation of and better knowledge of purposeful use.
I could give a lot more examples that underscore a different narrative. Not just because I spent almost 2 years of my life working this on a truly voluntary basis - I do not make a living from the ecosystem and my day job has no connection to it - but for the fact I sincerely believe that what was achieved was remarkable in and of itself.
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 /Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Wed, Jun 29, 2016 at 8:04 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Andrew,
I am sorry to take so long to respond to your very thoughtful message but as you know I have been pretty busy here in Helsinki. It seems to me personally that you make some suggestions that could possibly be constructive to the work ahead but I have two primary concerns:
1. I am pretty sure that it would require a charter change. To do that would require going back to the GNSO Council with the proposed changes and seeking their approval. That is something that is not out of the question but it could cause some delays and I would want to make sure that there is strong WG support for doing so. Also, I think we need to remember that a lot of very smart people spent quite a bit of time developing the framework that resulted in the charter so I think we should consider possible changes with that in mind.
2. My understanding is that EWG debated things like you are suggesting quite intensely. As you know I was not a member of the EWG but Lisa has provided some thoughts about that I include below.
" It might be useful to reflect upon the EWG's experience with system modeling. After starting with use cases, some EWG members needed a system model against which to test principles on purposes, data needs, and associated privacy, access, and accuracy issues. This led to the EWG's Initial Report proposing both a set of principles and an Aggregated RDS system model to support those principles - but without much explanation of the ARDS. Over the year that followed, the EWG evaluated half a dozen system models, drilling deeper into two (Federated and Synchronized) to examine feasibility and costs before recommending the SRDS. Both SRDS and FRDS models use RDAP; neither stores data in a single physical location. While the SRDS is a "thick" storage model where queries are served from synchronized data, the runner-up FRDS actually uses "thin" registries, querying data from registrars and validators in real-time.
"While some possible requirements may reflect a particular system model - for example, those drawn from today's WHOIS policies -- our PDP WG has yet to consider whether to recommend a next-gen system. But no matter what model we recommend, perhaps we can learn from the EWG's experience. First, while envisioning a possible new model early on was helpful to some, reaching agreement on a recommended model was not possible until the EWG was nearly finished, following feasibility and cost analysis. Second, while each had pros/cons, both models were found to be capable of supporting the EWG's principles. In other words, model choice did not drive the EWG's principles - principles and criteria such as cost drove the EWG's choice of model."
I want to add to Lisa's thoughts my own personal opinion: I don't think the issue of Federated v. Synchronized is a closed issue. My understanding is that the final recommendation in the EWG report could have been more the result of the desire to finish the work than a strong consensus. Whether I am right on that or not, our WG can consider both and make our own decision between either one or some variation.
Finally, I want to encourage all WG members to share your thoughts on Andrews comments and on my responses above.
Chuck
-----Original Message----- 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 Andrew Sullivan Sent: Friday, June 24, 2016 10:04 PM To: gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on requirements
Dear colleagues,
Apologies first. I'm not going to be in Helsinki. I'm in the middle of a move from NH back to Toronto, and it turns out that my movers' understanding of, "I need to leave on $date," entails arranging things such that goods will arrive after $date. Alas, in this case the goods arrive Monday. I will attempt to follow the ICANN meetings remotely next week, but I expect it will be tricky.
I have been deeply dissatisfied with the way the work is going, and I believe it is because I see a mismatch in what we are trying to do and the kind of system we are trying to do it to. In particular, I think we are trying to treat the RDS as a single monolithic system, and attempting to build "requirements" that match that assumption. Here is an effort to sketch why I think that. I didn't have time to write a short note, &c. &c. Sorry this is long.
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
The distribution comes from different parties having various parts of the data. In so-called "thin" registries, this was always the case. The registry has names and nameservers, and since the invention of registrars knows who the registrar is. But if you wanted to know certain kinds of data, you had to ask the registrar in question.
Because in (say) 1999-2001 nobody had anything better than the whois/rwhois/whois++ protocol(s) to deliver this kind of data, a whole bunch of bad compromises got enshrined in policy. First, we continued to use whois and its descendents (anything on port 43) as the model for all of this. The plain fact is that whois was obsolete nearly at birth. It's a terrible protocol, and should be taken behind the ice house and put out of its misery.
Second, in order to "fix up" whois, clients were created all over the Internet that built in a bunch of assumptions about whom to ask for what data. The consequence of this was that clients routinely got bad data as they queried the wrong server. Old registrar data hung around even after a transfer. When I worked on the org transition from Verisign to PIR in 2003 (?), it took a long time before whois clients stopped asking Verisign about org data. And so on.
Third, in an attempt to hack around the above technical flaws in an already-obsolete protocol, "thick whois" gained popularity in possibly the worst possible arrangement known to data science. Instead of insisting that registries hold the data and that registrars and everyone else treat the registry data as The Truth, we created "thick" whois in registries _without allowing registrars to stop their service_. Any half-competent database person will tell you that storing "the same data" in two places that don't have tight connections is an excellent way to create data inconsistency, but is not a good way to arrive at the truth. (Latterly, as though illustrating the tendency of people to double down on bad ideas, there have been suggestions that ICANN should run the One Giant RDS of the Universe and hold all the data in a central place. What could possibly go wrong?)
The thread running through this history of error is the idea that the RDS is one system. But like the DNS, it only appears to be one system. It's actually a "distributed database", where in this case the distribution is separable on organization lines. That is, registries -- including ICANN, who can be thought of in this case as both the registry and registrar for the root zone -- have some data. Registrars have some other data. Resellers and privacy/proxy services have yet other data. In many cases, the data does not need to be shared across these organizational lines to make it queryable by humans.
The reason that isn't clear to most of us is because whois -- the RDS we use today -- _was_ designed as a monolithic system. It was designed that way because back when it was created -- RFC 812 is from _1982_! -- the database _was_ a monolithic database. Whois (the protocol and the client program) continues to have all the deficiencies for distributed use that you might expect of a program or protocol designed to talk to exactly one authoritative service. Whois++ and rwhois attempted to graft on to this basic protocol some distributed operation, but the graft didn't really take and the ornamental shrub now looks like a weed.
People have nevertheless internalized the whois-based thinking, which is why we keep asking things like, "What data should be collected?" In a distributed system like this, that's barely interesting, for the commercial interests in this case all militate against collecting data that nobody needs for any function. Instead, we should ask what data should be collected _by different actors_. This implicitly involves describing what those actors are doing to require the data.
The nice thing, of course, is that protocol designers have done _a lot_ of this work for us, when they were working on RDAP. They did this because they were trying to come up with use cases for the protocol, which finally did away with the monolithic-system thinking of whois and offers us a protocol designed precisely to work in the distributed-database environment that is the actual registration system. That we even still have a work step that involves evaluating what protocol we're going to use for all this makes me a little ill.
It seems to me that we can just say that we have to embrace the distributed-database fact. For first, it's a fact of how registration actually works now. If we don't agree with that, I think we should give up. Second, it's consistent with how every single other thing on the Internet that has not crashed and burned works. The Internet cannot scale depending on monolithic systems. And nobody has the power to impose one anyway.
Once we have done that, there are still important policy issues about what data ought to be collected by anyone, under what conditions they might reveal it to someone else (and who that someone else is), and so on. But there are empirical tests for whether some of the answers people are proposing really match the distributed nature of the system. If they don't, we can close off those avenues of inquiry, because they'll never be productive.
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 https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- 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, Reading further in the thread, I realise that perhaps not everything that I said was perfectly clear. I'll respond to some other mails downthread, but before I do that I want to make sure we're all talking about the same thing. Some of this explanation is in some of the background material we have, but the relation to what I'm talking about obviously isn't. So here's some more explanation. This may be a little tedious for those already familiar with the history, but it seems better to lay this out in more detail so that it's clear what we're talking about. When I respond to other mails, I'll refer to these "Model I" through "Model V" descriptions, because these models are what I was thinking about when I wrote my earlier note. On Fri, Jun 24, 2016 at 10:03:33PM -0400, Andrew Sullivan wrote:
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
I have a feeling that people have conflated the "distributed" and "federated" discussion with some other points I was trying to make (and indeed, I'm not sure I was totally clear). So let me try to walk through a bunch of different ways that any RDS can work. I know that some people find diagrams easier, so I've tried to create some. I'm sorry I'm so bad at diagrams. Since email is a lousy way to inline diagrams, I'll make some references to some external diagrams I've shared. MODEL I Consider <https://docs.google.com/drawings/d/1KCLGP8pClFTLoGp1uqVF-ao80NRP3QAxkkies5h3...>. This is an approximate picture of the very earliest registration and RD systems. You registered a name with the NIC. The NIC also prepared the NICNAME directory, which was originally literally a document, published on paper. Oral histories tell me that the very earliest version of the "store" was a piece of paper kept in Jon Postel's pocket, but how true that is I don't know (I was certainly not involved at the time, since I was in senior elementary school and didn't have a connection to the Internet). There appear to have been small iterations on this model, but the central features are that, for any given registry (or registry operator, in fact), there is a single point of registration and a single source of data for any registr data service. I've called this Model I. To be clear, in this model there _could_ be multiple data sources for all registration data, because (for example) some country code TLDs ran their registries separately using this model. In that iteration of the model, whois clients had built-in lists of whois servers to consult. MODEL II The big change in the early whois evolution was the addition of rwhois and friends, which corresponded to the period in which registrars were added to the registration systems. I drew a diagram at <https://docs.google.com/drawings/d/1keKN1__qoboMQ2vEmsY6bnnUpLktQmF1GtjJ8hrM...>. This picture is the "thin registry" model. I've called it Model II. There are several features to note here. First, notice that the registration path involves a convolution. The registrant sends data to the registrar. The registrar has a bunch of needs for data, some of which are necessary for the business processes of the registrar and some of which are necessary for the functioning of the domain name. The registrar stores some or all of that data in a local registrar store. Also, such data as is needed for the registry is either passed through to the registry (the dotted line) or else copied from the registrar store to the registry (the solid line), using whatever protocol the registry used (some sort of registry-registrar protocol, or else EPP). The registry then also stores some data -- the data for registration (which is usually just the name, the registrar, and the name servers and necessary glue if provided). Second, in order to support this mode of working, whois had to change. The naïve use of a whois query (whois $domainname) required some adjustments. A client needs to know which server to start querying for a given domain name. (In general, even today, this is a static list compiled into the whois client, though many clients allow you to specify an alternate. In the earliest days, this feature was not widely deployed, which is how so much stale data "leaked out" -- people would query the wrong server, and get its answer.) When the registry whois server replied, it would provide a referral to the registrar's whois. Then the client would additionally query the registrar's whois, and get data like the name and contact of the registrant and so on. The client would assemble this somehow, and then present it to the user. Note that this last step might not be using the whois protcol -- in particular, most of the "web whois" systems are basically a user interface via http(s) to a port 43 whois client. As an aside, it's worth noting that the "referral" part of this system didn't work that well, mostly because of the whois protocol. Whois was designed to be read by humans, so the protocol is dead stupid: connect to port 43, send a string, and receive a bunch of strings back. There is no data format whatsoever, and therefore when you wanted to communicate something machine-readable in the data that came back (like, for instance, "here's a referral"), there was no reliable way to do it. Instead, the client had to parse the response and figure out which parts were supposed to be instructions to the client instead of something the human should see. This is perhaps the least-reliable way to make a protocol ever, and it didn't work very well. The many efforts to standardise whois output formats within ICANN have all been gross hacks on top of this basic problem: if you make the output format sufficietly consistent, machines get better at processing that output. (This is why rwhois got better over time -- see below.) Third, because a client can initiate a query directly against a whois server, the client could ask a registrar who is no longer the actual registrar for a name about that name. This can result in "wrong" data, because the registrar might have lost the registration in the past and have old data hanging around. This was at one time a major problem, and an awful lot of policy that exists today is quite obviously an attempt to solve this problem (which is as a matter of fact no longer really that interesting -- the technical reality has made some of that policy obsolete, but people continue to insist on solving a problem they had in 1999). Note that this model is the beginning of what I was describing as a "distributed system". Data comes from multiple sources, and it is assembled by the end client into a whole that answers the initial query. Finally, note that I've drawn this with common data stores for registration and whois at the registry and registrar. In implementation, the actual database systems that the whois servers use might be different than the one the registration servers use, and there might even be some transformation (one system I worked on, for instance, precompiled whois answers so that the whois server went faster). But the point is that the data store is operated by the same operator as the registration database (i.e. the operator of the RDS is the operator of the server that accepts the incoming data). MODEL III Partly in response to the unreliability of rwhois, and partly I suspect because people didn't really trust registrars to do their job, many registries (some for contractual reasons) adopted a "thick whois" model. This is just a patch on top of Model II: <https://docs.google.com/drawings/d/183F855BODDVIt0IriSGU35EyoaLYpLQMUxAk4RsN...>. The basic system works exactly the same way, but when the client queries the registry whois server it gets a complete response instead of having to ask the registrar for more data. For reasons I never fully understood, registrars still had to maintain a whois server for these registries, so it remains possible to ask a registrar about a domain name (the orange lines in the diagram). Just as in Model II, the registrar will respond with what it has, which might not be correct. But you're way less likely to ask the registrar unless you're on purpose querying the wrong place. This is the model that most contracted registries are using today. It is slightly less distributed than Model II because the registries provide the data from a central point for that registry. It's still distributed in that each registry answers for its area of authority. MODEL IV I've illustrated the basic approach that I think most of us involved in specifying RDAP had in mind in <https://docs.google.com/drawings/d/1HftBWzxA4DGwa0-PMCrpxXkK0Nwpm8ZS8Rsql6Vt...>. This is fundamentally a modification of Model II, in that it is a distributed query and distributed store system. RDAP does some things differently, however. First, its output is JSON documents, which can be used reliably in multiple different ways (including being parsed by a machine or formatted for presentation to humans). Second, there's a bootstrap mechanism in which, to get started, you query IANA. Note that some whois clients had already started to do this for Model II, but it was nowhere specified. Now it's just part of how things work. Finally, RDAP has built in the idea that the client could be authenticated. This automatically means that different responses can be returned depending on the credentials the client presents. Note that the protocol for this is all https, so there's no more port 43 traffic arising from this. Note also that you can do the same sort of thing with a "thick registry" model -- the registry doesn't send a referral in that case. This model is exactly as distributed as Model II or III, depending on which approach we take. MODEL V Model V is a little harder to illustrate, because it's not clear (especially in our discussions) what protocols it'd use. Nevertheless, I've sketched it at <https://docs.google.com/drawings/d/1c3G3guMO7-IFtm-D1FIdEXXP9_ww8Op4Ul9N1ypT...>. The key thing here is to notice that the model takes a bunch of data from disparate sources, federates it (somehow) into a single data store, and then offers the federated RDS to clients that query from the Internet. There are some interesting consequences of this. First, note that this is the only model in which the answers to an RDS query come from a party that is not directly responsible for collecting some data. Model III went partway toward that by having registries hold data that is really only relevant to registrars. Model V takes this all the way to its conclusion, in that the data store backing the RDS is operated by someone who doesn't collect any of that data from the original source. Second, in order to make this happen, a federation process of some kind needs to be designed, written, and tested. Presumably the RDS could use RDAP or whois for its protocols, or we could specify that we need something else. I believe that the IETF will only support RDAP for this use, so if we decide to specify that some other protocol is needed then I guess we'll have to find someone to develop that specification before we can proceed. Finally, this model is as monolithic as the system can get: it basically re-invents the Whois model of the pre-registrar period, when the data in the WHOIS was small enough that it could be put into a mimeographed booklet. I hope this is helpful. A -- Andrew Sullivan ajs@anvilwalrusden.com
Thanks, Andrew. This is VERY helpful. Model V is the one I'd build if I weren't so concerned about the plethora of local privacy laws and law enforcement regimes. One we have a single repository owned by ICANN, we have a single entity which may be pressured by law enforcement or government agencies world-wide to divulge PII. Where that repository resides is also of concern due to issues of jurisdiction. Lastly, the ownership of the repository and the operation of the associated web services must fall upon ICANN with all the cost and SLA concerns already raised by the community. For these reasons, I prefer a nonfederated approach such as Model 4. /marksv -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 7:35 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Five models of RDS (was Re: Apologies, and some reflections on requirements) Hi, Reading further in the thread, I realise that perhaps not everything that I said was perfectly clear. I'll respond to some other mails downthread, but before I do that I want to make sure we're all talking about the same thing. Some of this explanation is in some of the background material we have, but the relation to what I'm talking about obviously isn't. So here's some more explanation. This may be a little tedious for those already familiar with the history, but it seems better to lay this out in more detail so that it's clear what we're talking about. When I respond to other mails, I'll refer to these "Model I" through "Model V" descriptions, because these models are what I was thinking about when I wrote my earlier note. On Fri, Jun 24, 2016 at 10:03:33PM -0400, Andrew Sullivan wrote:
Since the very introduction of the competitive-registrar model (and arguably before that), the RDS has been a distributed database. It is far less successful than the other distrubuted database we all know and love -- DNS -- but it is nevertheless distributed.
I have a feeling that people have conflated the "distributed" and "federated" discussion with some other points I was trying to make (and indeed, I'm not sure I was totally clear). So let me try to walk through a bunch of different ways that any RDS can work. I know that some people find diagrams easier, so I've tried to create some. I'm sorry I'm so bad at diagrams. Since email is a lousy way to inline diagrams, I'll make some references to some external diagrams I've shared. MODEL I Consider <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.google...>. This is an approximate picture of the very earliest registration and RD systems. You registered a name with the NIC. The NIC also prepared the NICNAME directory, which was originally literally a document, published on paper. Oral histories tell me that the very earliest version of the "store" was a piece of paper kept in Jon Postel's pocket, but how true that is I don't know (I was certainly not involved at the time, since I was in senior elementary school and didn't have a connection to the Internet). There appear to have been small iterations on this model, but the central features are that, for any given registry (or registry operator, in fact), there is a single point of registration and a single source of data for any registr data service. I've called this Model I. To be clear, in this model there _could_ be multiple data sources for all registration data, because (for example) some country code TLDs ran their registries separately using this model. In that iteration of the model, whois clients had built-in lists of whois servers to consult. MODEL II The big change in the early whois evolution was the addition of rwhois and friends, which corresponded to the period in which registrars were added to the registration systems. I drew a diagram at <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.google...>. This picture is the "thin registry" model. I've called it Model II. There are several features to note here. First, notice that the registration path involves a convolution. The registrant sends data to the registrar. The registrar has a bunch of needs for data, some of which are necessary for the business processes of the registrar and some of which are necessary for the functioning of the domain name. The registrar stores some or all of that data in a local registrar store. Also, such data as is needed for the registry is either passed through to the registry (the dotted line) or else copied from the registrar store to the registry (the solid line), using whatever protocol the registry used (some sort of registry-registrar protocol, or else EPP). The registry then also stores some data -- the data for registration (which is usually just the name, the registrar, and the name servers and necessary glue if provided). Second, in order to support this mode of working, whois had to change. The naïve use of a whois query (whois $domainname) required some adjustments. A client needs to know which server to start querying for a given domain name. (In general, even today, this is a static list compiled into the whois client, though many clients allow you to specify an alternate. In the earliest days, this feature was not widely deployed, which is how so much stale data "leaked out" -- people would query the wrong server, and get its answer.) When the registry whois server replied, it would provide a referral to the registrar's whois. Then the client would additionally query the registrar's whois, and get data like the name and contact of the registrant and so on. The client would assemble this somehow, and then present it to the user. Note that this last step might not be using the whois protcol -- in particular, most of the "web whois" systems are basically a user interface via http(s) to a port 43 whois client. As an aside, it's worth noting that the "referral" part of this system didn't work that well, mostly because of the whois protocol. Whois was designed to be read by humans, so the protocol is dead stupid: connect to port 43, send a string, and receive a bunch of strings back. There is no data format whatsoever, and therefore when you wanted to communicate something machine-readable in the data that came back (like, for instance, "here's a referral"), there was no reliable way to do it. Instead, the client had to parse the response and figure out which parts were supposed to be instructions to the client instead of something the human should see. This is perhaps the least-reliable way to make a protocol ever, and it didn't work very well. The many efforts to standardise whois output formats within ICANN have all been gross hacks on top of this basic problem: if you make the output format sufficietly consistent, machines get better at processing that output. (This is why rwhois got better over time -- see below.) Third, because a client can initiate a query directly against a whois server, the client could ask a registrar who is no longer the actual registrar for a name about that name. This can result in "wrong" data, because the registrar might have lost the registration in the past and have old data hanging around. This was at one time a major problem, and an awful lot of policy that exists today is quite obviously an attempt to solve this problem (which is as a matter of fact no longer really that interesting -- the technical reality has made some of that policy obsolete, but people continue to insist on solving a problem they had in 1999). Note that this model is the beginning of what I was describing as a "distributed system". Data comes from multiple sources, and it is assembled by the end client into a whole that answers the initial query. Finally, note that I've drawn this with common data stores for registration and whois at the registry and registrar. In implementation, the actual database systems that the whois servers use might be different than the one the registration servers use, and there might even be some transformation (one system I worked on, for instance, precompiled whois answers so that the whois server went faster). But the point is that the data store is operated by the same operator as the registration database (i.e. the operator of the RDS is the operator of the server that accepts the incoming data). MODEL III Partly in response to the unreliability of rwhois, and partly I suspect because people didn't really trust registrars to do their job, many registries (some for contractual reasons) adopted a "thick whois" model. This is just a patch on top of Model II: <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.google...>. The basic system works exactly the same way, but when the client queries the registry whois server it gets a complete response instead of having to ask the registrar for more data. For reasons I never fully understood, registrars still had to maintain a whois server for these registries, so it remains possible to ask a registrar about a domain name (the orange lines in the diagram). Just as in Model II, the registrar will respond with what it has, which might not be correct. But you're way less likely to ask the registrar unless you're on purpose querying the wrong place. This is the model that most contracted registries are using today. It is slightly less distributed than Model II because the registries provide the data from a central point for that registry. It's still distributed in that each registry answers for its area of authority. MODEL IV I've illustrated the basic approach that I think most of us involved in specifying RDAP had in mind in <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.google...>. This is fundamentally a modification of Model II, in that it is a distributed query and distributed store system. RDAP does some things differently, however. First, its output is JSON documents, which can be used reliably in multiple different ways (including being parsed by a machine or formatted for presentation to humans). Second, there's a bootstrap mechanism in which, to get started, you query IANA. Note that some whois clients had already started to do this for Model II, but it was nowhere specified. Now it's just part of how things work. Finally, RDAP has built in the idea that the client could be authenticated. This automatically means that different responses can be returned depending on the credentials the client presents. Note that the protocol for this is all https, so there's no more port 43 traffic arising from this. Note also that you can do the same sort of thing with a "thick registry" model -- the registry doesn't send a referral in that case. This model is exactly as distributed as Model II or III, depending on which approach we take. MODEL V Model V is a little harder to illustrate, because it's not clear (especially in our discussions) what protocols it'd use. Nevertheless, I've sketched it at <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.google...>. The key thing here is to notice that the model takes a bunch of data from disparate sources, federates it (somehow) into a single data store, and then offers the federated RDS to clients that query from the Internet. There are some interesting consequences of this. First, note that this is the only model in which the answers to an RDS query come from a party that is not directly responsible for collecting some data. Model III went partway toward that by having registries hold data that is really only relevant to registrars. Model V takes this all the way to its conclusion, in that the data store backing the RDS is operated by someone who doesn't collect any of that data from the original source. Second, in order to make this happen, a federation process of some kind needs to be designed, written, and tested. Presumably the RDS could use RDAP or whois for its protocols, or we could specify that we need something else. I believe that the IETF will only support RDAP for this use, so if we decide to specify that some other protocol is needed then I guess we'll have to find someone to develop that specification before we can proceed. Finally, this model is as monolithic as the system can get: it basically re-invents the Whois model of the pre-registrar period, when the data in the WHOIS was small enough that it could be put into a mimeographed booklet. I hope this is helpful. A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or...
On Thu, Jun 30, 2016 at 07:32:45PM +0000, Mark Svancarek wrote:
Model V is the one I'd build if I weren't so concerned about the plethora of local privacy laws and law enforcement regimes.
There is another thing about Model V I didn't point out but that I think is worth noting. Model V is monolithic in that anyone on the whole Internet who wants to look at anything out of the RDS has to contact this single service. Everything we know about how the Internet has scaled well suggests that monolithic services are extremely hard to do well. The things that have really gotten huge are of two types: 1. Distributed systems that are mostly cheap to operate. Think DNS, the web, and so on. Certain large operators have an expensive installation, but no individual service is super expensive to operate and if it fails it doesn't take down the class of service completely. 2. Massive single-company category killers that depend on advertising revenue, revenue gained by knowing a lot about users and selling that, money dependent on a "magic happens here" belief on the part of investors, or paid use (or all of these). Think Google, Facebook, Twitter, Office360, and Amazon (both the commerce site and AWS) -- or maybe pets.com for the third category of these. Notable here is that if the operator has a bad day the entire _class_ of service disappears. There is no alternative Facebook: if they're broken, Facebook stops. (Fortunately, they're very, very good and rarely have this happen; but that's not an operation built on a shoestring.) The plan for a monolithic RDS is basically to build (2) and hope that revenues and operations staff adequate to (1) will be enough. I hope it is self-evident what the problem is here. Moreover, I hope that everyone involved in this WG is familiar enough with the term "DDoS" to see why building a Big Giant Centralised Service might be like painting a target on ICANN. Or perhaps _another_ target. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Yes, I should clarify my statement, because I contradicted myself a bit. I really only like Model V if someone I trust is running it :) That's why I mentioned my concern about ICANN SLA. I don't think they are ready to run a 99.999% online service. Sorry for the confusion. -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, June 30, 2016 11:03 PM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Five models of RDS (was Re: Apologies, and some reflections on requirements) On Thu, Jun 30, 2016 at 07:32:45PM +0000, Mark Svancarek wrote:
Model V is the one I'd build if I weren't so concerned about the plethora of local privacy laws and law enforcement regimes.
There is another thing about Model V I didn't point out but that I think is worth noting. Model V is monolithic in that anyone on the whole Internet who wants to look at anything out of the RDS has to contact this single service. Everything we know about how the Internet has scaled well suggests that monolithic services are extremely hard to do well. The things that have really gotten huge are of two types: 1. Distributed systems that are mostly cheap to operate. Think DNS, the web, and so on. Certain large operators have an expensive installation, but no individual service is super expensive to operate and if it fails it doesn't take down the class of service completely. 2. Massive single-company category killers that depend on advertising revenue, revenue gained by knowing a lot about users and selling that, money dependent on a "magic happens here" belief on the part of investors, or paid use (or all of these). Think Google, Facebook, Twitter, Office360, and Amazon (both the commerce site and AWS) -- or maybe pets.com for the third category of these. Notable here is that if the operator has a bad day the entire _class_ of service disappears. There is no alternative Facebook: if they're broken, Facebook stops. (Fortunately, they're very, very good and rarely have this happen; but that's not an operation built on a shoestring.) The plan for a monolithic RDS is basically to build (2) and hope that revenues and operations staff adequate to (1) will be enough. I hope it is self-evident what the problem is here. Moreover, I hope that everyone involved in this WG is familiar enough with the term "DDoS" to see why building a Big Giant Centralised Service might be like painting a target on ICANN. Or perhaps _another_ target. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or...
ICANN doend’t “run” most of the things coming under it’s remit or in the ecosystem it’s policies guide. Any sort of RDS system regardless of model would likely fall into this category as well. I thinks a few of the large registries run 5 9 operations for example…
On Jun 30, 2016, at 11:15 PM, Mark Svancarek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
That's why I mentioned my concern about ICANN SLA. I don't think they are ready to run a 99.999% online service.
Sorry for the confusion.
That's why I'd be concerned 😃 Sent from my Windows Phone ________________________________ From: Rod Rasmussen<mailto:rrasmussen@infoblox.com> Sent: 7/1/2016 6:27 AM To: Mark Svancarek<mailto:marksv@microsoft.com> Cc: Andrew Sullivan<mailto:ajs@anvilwalrusden.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Five models of RDS (was Re: Apologies, and some reflections on requirements) ICANN doend’t “run” most of the things coming under it’s remit or in the ecosystem it’s policies guide. Any sort of RDS system regardless of model would likely fall into this category as well. I thinks a few of the large registries run 5 9 operations for example…
On Jun 30, 2016, at 11:15 PM, Mark Svancarek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
That's why I mentioned my concern about ICANN SLA. I don't think they are ready to run a 99.999% online service.
Sorry for the confusion.
Thank you for taking the time to outline the architecture of the existing WHOIS service and how it has evolved over time, Andrew. With this background and your extremely useful diagrams I now have a much clearer understanding of to what extent different parties wield control (or not) over the data of registrants. I am not going to be able to enter into any conversation where we are debating the finer technical points of how a protocol functions, but I can comment on more focused policy applications. Certainly I do not want to contribute to any degradation of what has made the Internet what it is today – a place for limitless innovation and where users trust it as safe and secure environment for commerce and communication. I have tried my best not to approach this working group with any pre-conceived ideas as to what I would like the final outcome to be (partially because I do not have the institutional knowledge to even formulate these ideas in the first place ), but I lay my cards out on the table and say it is very important to me that the Internet’s growth is not impeded in any way. I worry, looking at Model V in particular, that we could end up in a situation where we all end up wishing a different approach could have been taken. We could very well end up with an outcome where the reasons behind establishing this working group are not addressed, where ICANN or another party is stuck with huge costs, and where the Internet’s growth and evolution is permanently stifled. There are six issues that I see with Model V, four of which Mark has already outlined: questions around jurisdiction, privacy, cost, and service level agreements/overall accountability. I would also like us to consider potential liability for the manager of the federated store for data breaches (and liability for those who have retrieved data from the RDS and have lost it once it was in their possession), along with the potential anti-trust implications of there being one, privately-owned database which all gTLD registries must use. What I like about the Internet, as we know it today, is that it is for everyone. There is no central authority that permits different classes of Internet activities, which means it is possible for anyone to connect to the network and to build new parts of it. This innovation (which happens organically, without requiring permission) has come about because the Internet’s technologies are based on interoperability and reusable building blocks that might have been built for one purpose but have come to support some other important function at a later date. This is what I want to continue happening. A distributed RDS which anyone can improve through cooperation and collaboration, because its success depends on its continued relevance and utility, and not on some arbitrary clause in a contract that prioritises 'incumbation' (for lack of a better word) over innovation. I understand that we are not yet at a stage where we should be deliberating on what the RDS should look like (if we even conclude one is required), so before I continue to outline my strong opposition to Model V, may I please clarify: where did the idea for this federated RDS originate from? Is it just because in the wish list of possible requirements we have to consider, a few suggested a federated system? Or is there something more concrete in the works? (And if so, can you please link me to any IETF discussions on this?) Thank you. Thank you again, Andrew, for taking the time to go back to basics. The diagrams you have produced of how WHOIS-related protocols and services have evolved over time have left me much more informed of the differences between 'thick' and 'thin' registries than I was a few days ago. Best wishes, Ayden On Fri, Jul 1, 2016 5:52 AM, Mark Svancarek via gnso-rds-pdp-wg gnso-rds-pdp-wg@icann.org wrote: That's why I'd be concerned 😃 Sent from my Windows Phone -------------------------------------------------------------------------------- From: Rod Rasmussen Sent: 7/1/2016 6:27 AM To: Mark Svancarek Cc: Andrew Sullivan ; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Five models of RDS (was Re: Apologies, and some reflections on requirements) ICANN doend’t “run” most of the things coming under it’s remit or in the ecosystem it’s policies guide. Any sort of RDS system regardless of model would likely fall into this category as well. I thinks a few of the large registries run 5 9 operations for example…
On Jun 30, 2016, at 11:15 PM, Mark Svancarek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
That's why I mentioned my concern about ICANN SLA. I don't think they are ready to run a 99.999% online service.
Sorry for the confusion.
Ayden Férdeline Statement of Interest
Thanks Ayden for taking the time to express your thoughts. I will let those who were on the EWG to respond in more detail to your questions if they like but I will share my understanding. The EWG report recommended the federated model as one of its last decisions. That said, I want to make it very clear that our WG does not have to accept that recommendation, and based on arguments that have been made on this list, I am convinced that we will seriously question it when the time comes. But please note that I am not inviting discussion of that now; it will come quite a bit later in our work. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Ayden Férdeline Sent: Sunday, July 03, 2016 8:35 AM To: Mark Svancarek; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Five models of RDS (was Re: Apologies, and some reflections on requirements) Thank you for taking the time to outline the architecture of the existing WHOIS service and how it has evolved over time, Andrew. With this background and your extremely useful diagrams I now have a much clearer understanding of to what extent different parties wield control (or not) over the data of registrants. I am not going to be able to enter into any conversation where we are debating the finer technical points of how a protocol functions, but I can comment on more focused policy applications. Certainly I do not want to contribute to any degradation of what has made the Internet what it is today – a place for limitless innovation and where users trust it as safe and secure environment for commerce and communication. I have tried my best not to approach this working group with any pre-conceived ideas as to what I would like the final outcome to be (partially because I do not have the institutional knowledge to even formulate these ideas in the first place [😉] ), but I lay my cards out on the table and say it is very important to me that the Internet’s growth is not impeded in any way. I worry, looking at Model V in particular, that we could end up in a situation where we all end up wishing a different approach could have been taken. We could very well end up with an outcome where the reasons behind establishing this working group are not addressed, where ICANN or another party is stuck with huge costs, and where the Internet’s growth and evolution is permanently stifled. There are six issues that I see with Model V, four of which Mark has already outlined: questions around jurisdiction, privacy, cost, and service level agreements/overall accountability. I would also like us to consider potential liability for the manager of the federated store for data breaches (and liability for those who have retrieved data from the RDS and have lost it once it was in their possession), along with the potential anti-trust implications of there being one, privately-owned database which all gTLD registries must use. What I like about the Internet, as we know it today, is that it is for everyone. There is no central authority that permits different classes of Internet activities, which means it is possible for anyone to connect to the network and to build new parts of it. This innovation (which happens organically, without requiring permission) has come about because the Internet’s technologies are based on interoperability and reusable building blocks that might have been built for one purpose but have come to support some other important function at a later date. This is what I want to continue happening. A distributed RDS which anyone can improve through cooperation and collaboration, because its success depends on its continued relevance and utility, and not on some arbitrary clause in a contract that prioritises 'incumbation' (for lack of a better word) over innovation. I understand that we are not yet at a stage where we should be deliberating on what the RDS should look like (if we even conclude one is required), so before I continue to outline my strong opposition to Model V, may I please clarify: where did the idea for this federated RDS originate from? Is it just because in the wish list of possible requirements we have to consider, a few suggested a federated system? Or is there something more concrete in the works? (And if so, can you please link me to any IETF discussions on this?) Thank you. Thank you again, Andrew, for taking the time to go back to basics. The diagrams you have produced of how WHOIS-related protocols and services have evolved over time have left me much more informed of the differences between 'thick' and 'thin' registries than I was a few days ago. Best wishes, Ayden [https://app.mixmax.com/api/track/v2/hzbgKWNfBGf5urBIl/i02bj5SZulGblRmclZGQu5...] On Fri, Jul 1, 2016 5:52 AM, Mark Svancarek via gnso-rds-pdp-wg gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> wrote: That's why I'd be concerned 😃 Sent from my Windows Phone ________________________________ From: Rod Rasmussen<mailto:rrasmussen@infoblox.com> Sent: 7/1/2016 6:27 AM To: Mark Svancarek<mailto:marksv@microsoft.com> Cc: Andrew Sullivan<mailto:ajs@anvilwalrusden.com>; gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Five models of RDS (was Re: Apologies, and some reflections on requirements) ICANN doend’t “run” most of the things coming under it’s remit or in the ecosystem it’s policies guide. Any sort of RDS system regardless of model would likely fall into this category as well. I thinks a few of the large registries run 5 9 operations for example…
On Jun 30, 2016, at 11:15 PM, Mark Svancarek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote:
That's why I mentioned my concern about ICANN SLA. I don't think they are ready to run a 99.999% online service.
Sorry for the confusion.
Ayden Férdeline Statement of Interest<https://community.icann.org/display/gnsosoi/Ayden+Férdeline+SOI>
participants (23)
-
Andrew Sullivan -
Ayden Férdeline -
Carlton Samuels -
Catalyst-Vaibhav Aggarwal -
DANIEL NANGHAKA -
Farell Folly -
Gomes, Chuck -
Greg Aaron -
Group CEO-Vaibhav Aggarwal
-
James Gannon -
John Bambenek -
Kiran Malancharuvil -
Mark Svancarek -
Michele Neylon - Blacknight -
Nathalie Coupet -
Rob Golding -
Rod Rasmussen -
Shane Kerr -
Stephanie Perrin -
Susan Kawaguchi -
TXVB -
Victoria Sheckler -
Volker Greimann