<html>
<body>
Indeed, and I don't suppose anyone would dispute that. But note that some
of this information, although it does not go into the current Whois, is
under the RAA, subject to verification, specifically, the Account holder
(generally the entity that pays for the domains if not the same as the
registrant).<br><br>
Alan<br><br>
At 07/10/2016 04:15 PM, Stephanie Perrin wrote:<br><br>
<blockquote type=cite class=cite cite=""><font size=1>Well the registrar
has quite a bit of information about the registrant that is not
necessarily in the RDS/WHOIS.<br>
</font><br>
<font size=1>SP</font><br><br>
On 2016-10-07 14:20, Richard Leaning wrote:<br>
<blockquote type=cite class=cite cite="">Thats Greg for articulating it
so well. <br><br>
all i was going to say was - <br><br>
'You can’t contact someone if the contact information is
inaccurate’<br><br>
So i can’t see how you can split the two.<br><br>
Richard Leaning<br>
External Relations<br>
RIPE NCC<br><br>
<br><br>
<br>
<blockquote type=cite class=cite cite="">On 7 Oct 2016, at 17:21, Greg
Shatan
<<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>
> wrote:<br><br>
It might be useful to bring in the findings of the WHOIS review team on
this point. There have been multiple discussions of contactability
and accuracy in various ICANN groups. <br><br>
We don't need to choose between "accuracy" and
"contactability" to have this discussion. Quite the
opposite. These are related concepts and our discussion needs
to consider both concepts. Contactability can be correlated to
"functional accuracy" and also to certain amount of "fault
tolerance" in the data. Inaccuracy in some fields is highly
detrimental to contactability, in others not so much. Sometimes a
certain combination of inaccuracies is fatal to contactability. In
other words, contactability informs the discussion of accuracy, and vice
versa.<br><br>
Greg<br><br>
On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin
<<a href="mailto:stephanie.perrin@mail.utoronto.ca">
stephanie.perrin@mail.utoronto.ca</a>> wrote:<br>
<dl><br>
<dd><font size=1>Indeed, I think we should talk about contactable, not
"accurate". This was the result of similar discussions of
the WHOIS review team, as I understand it, accuracy was defined as
contactable. It makes sense to me. I realize that others want
more data and more accuracy, but that is their goal, not necessarily the
goal of this pdp. The goal of privacy advocates, or those who wish
to see data protection law implemented (and I do realize we are few in
number) is to minimize the collection of information to what is
necessary.<br>
</font><br>
<dd><font size=1>Stephanie</font><br><br>
<dd>On 2016-10-07 08:27, Michele Neylon - Blacknight wrote:<br>
<blockquote type=cite class=cite cite=""><br>
<dd>Stephanie<br><br>
<dd>Here’s one we run into all the time: <br><br>
<dd>A lot of our clients in Northern Ireland do not view themselves as
being part of the UK, so they’ll choose to list their country as
“Ireland’.<br><br>
<dd>Is the data they supply “bad”? Strictly speaking yes<br><br>
<dd>Are they still reachable? Of course they are.<br><br>
<dd>Regards<br><br>
<dd>Michele<br><br>
<dd>--<br><br>
<dd>Mr Michele Neylon<br><br>
<dd>Blacknight Solutions<br><br>
<dd>Hosting, Colocation & Domains<br><br>
<dd><a href="http://www.blacknight.host/">http://www.blacknight.host/</a>
<br><br>
<dd><a href="http://blacknight.blog/" eudora="autourl">
http://blacknight.blog/</a><br><br>
<dd><a href="http://www.blacknight.press/">http://www.blacknight.press</a>
- get our latest news & media coverage<br><br>
<dd><a href="http://www.technology.ie/">http://www.technology.ie</a><br>
<br>
<dd>Intl. +353 (0) 59 9183072<br><br>
<dd>Direct Dial: +353 (0)59 9183090<br><br>
<dd>Social:
<a href="http://mneylon.social/">http://mneylon.social</a><br><br>
<dd>Random Stuff:
<a href="http://michele.irish/">http://michele.irish</a> <br><br>
<dd>-------------------------------<br><br>
<dd>Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business
Park,Sleaty<br><br>
<dd>Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.:
370845<br><br>
<dd> <br><br>
<dd>From:
</b><a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
<gnso-rds-pdp-wg-bounces@icann.org></a> on behalf of Stephanie
Perrin
<a href="mailto:stephanie.perrin@mail.utoronto.ca">
<stephanie.perrin@mail.utoronto.ca></a><br>
<dd>Date: </b>Friday 7 October 2016 at 00:42<br>
<dd>To: </b>Mark Svancarek
<a href="mailto:marksv@microsoft.com"><marksv@microsoft.com></a>,
<a href="mailto:gnso-rds-pdp-wg@icann.org">
"gnso-rds-pdp-wg@icann.org"</a>
<a href="mailto:gnso-rds-pdp-wg@icann.org">
<gnso-rds-pdp-wg@icann.org></a><br>
<dd>Subject: </b>Re: [gnso-rds-pdp-wg] For your review - updated RDS
Statement of Purpose<br><br>
<dd> <br><br>
<dd>Not at all, ordinary people make mistakes all the time.
However, rarely would this kind of mistake render the person/organization
un-contactable, which it seems to me is the evil we are trying to avoid
with bad data. On the other hand, criminals have a goal of being
untraceable, so will continue to make sure they are not located,
right?<br><br>
<dd>SP<br><br>
<dd> <br><br>
<dd>On 2016-10-06 19:20, Mark Svancarek wrote:<br>
<dl><br>
<dd>There seems to be a presumption that bad data is caused entirely by
bad people. <br><br>
<dd>Do we actually have data showing which fraction of bad data is
created with criminal intent, and which fraction is just people being
lazy or careless and then never being held accountable by the data
actually being verified?<br><br>
<dd><a name="m_2007596586480275167__MailEndCompose"></a> <br><br>
<dd>From:</b>
<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
gnso-rds-pdp-wg-bounces@icann.org</a>
[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] On Behalf Of </b>Stephanie
Perrin<br>
<dd>Sent:</b> Thursday, October 6, 2016 3:09 PM<br>
<dd>To:</b>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br>
<dd>Subject:</b> Re: [gnso-rds-pdp-wg] For your review - updated RDS
Statement of Purpose<br><br>
<dd> <br><br>
<dd>I agree with those pushing back on including a commitment to accuracy
in this statement of purpose. I think there are a number of sound
reasons for this. Those of us who push back are not advocating for
bad data, that would be silly. What we are addressing is the
futility of attempting to get the criminal element to put good data in
their registration data. If we force them, we drive ID theft.
Here are a few of my reasons:<br><br>
<dd>1. Governments actually do not usually invest taxpayers money
verifying citizen data, they provide penalties for having inaccurate data
and leave it at that. Verifying address and phone number, given the
mobility of the population in the countries I am familiar with from my
past government service (US, Canada, Australia, New Zealand, and UK) is
expensive and there is very little way to enforce it. This being
the case, why would we force ICANN to do this? The cost inevitably
would fall on the Registrars and registries, and be passed on to the end
users.<br><br>
<dd>2. As mentioned above, any pressure to improve data quality can
hardly be expected to get criminals to give their accurate data, it will
drive them to steal good data.<br><br>
<dd>3. The vast majority of people are actually honest. I do
realize that there is a high volume of cybercrime, but penalizing the
majority of end users for the actions of a few (even if those actions
result in a high volume of phishing and malware etc) is not good
policy. There are other ways to catch and dump bad domains.
Prosecution of malfeasant registrants remains a problem, but frankly how
many can be prosecuted across borders anyway?<br><br>
<dd>4. We do have questions about accuracy that we need to address,
according to our charter. The purpose of this purpose statement is
to boil down our business requirements for the activity in which we are
engaged. While many actors want more accurate data, how to get that
accuracy is so open to question that I regard its inclusion in the
statement of purpose as setting impossible goals. I would be happy
to revise this sentence as follows:<br><br>
<dd>To enable release of accurate gTLD registration data that may not
otherwise be publicly available, under specific and explicit
policy-defined conditions Change to <br><br>
<dd> <br><br>
<dd>To enable release of gTLD registration data that may not otherwise be
publicly available under specific conditions defined by policy, and to
develop mechanisms to encourage greater accuracy of data.<br><br>
<dd>Stephanie Perrin<br><br>
<dd>On 2016-10-06 16:48, Chris Pelling wrote:<br>
<dl><br>
<dd>Hi Nick,<br><br>
<dd> <br><br>
<dd>I would actually concur with Volker. I see your point but, can
I ask a question, the data collected cannot be proven to any certainty
because we have nothing as the registry/registrar community to
"check" it against. Simply checking say the address
against a city, against a State, against a postal/zip code then country
isnt proving the registrant data is correct, its simply proving that the
registrant can open a phone book and pick an address out.<br><br>
<dd> <br><br>
<dd>Until tools are created to prove that registrant is actually at
address X, accuracy is a rather moot point.<br><br>
<dd> <br><br>
<dd>I agree with your point about law enforcement and bad data being a
cost to the public purse, but until the governments can get together and
work out a solution for the data to be verified there is little anyone
can do.<br><br>
<dd> <br><br>
<dd>Registrant giving fake address = bad data<br><br>
<dd>Registrant giving correct address of neighbour = bad data<br><br>
<dd>Registrant giving old address where previously lived = bad data - but
at least it could be validated against old correct data and cross
checked<br><br>
<dd> <br><br>
<dd>This list could be endless :<br><br>
<dd> <br><br>
<dd>Registrant giving correct data = good, verifiable. Maybe
the governments can work out a solution to being able to verify their
citizens data.<br><br>
<dd> <br><br>
<dd>I would love to find a solution that is workable and commercially
viable, the governments and LEA can then use the data with some surety to
its worthiness - although this is a totally separate topic, I would like
to sit down and discuss it further - the governments getting together and
helping this work.<br><br>
<dd> <br><br>
<dd>Just a thought.<br><br>
<dd> <br><br>
<dd>Kind regards,<br><br>
<dd>Chris<br><br>
<dd> <br>
<hr>
<div align="center"></div>
<dd>From: </b>"Nick Shorey"
<a href="mailto:nick.shorey@culture.gov.uk">
<nick.shorey@culture.gov.uk></a><br>
<dd>To: </b>"Volker Greimann"
<a href="mailto:vgreimann@key-systems.net">
<vgreimann@key-systems.net></a><br>
<dd>Cc: </b>"gnso-rds-pdp-wg"
<a href="mailto:gnso-rds-pdp-wg@icann.org">
<gnso-rds-pdp-wg@icann.org></a><br>
<dd>Sent: </b>Thursday, 6 October, 2016 17:38:55<br>
<dd>Subject: </b>Re: [gnso-rds-pdp-wg] For your review - updated RDS
Statement of Purpose<br><br>
<dd> <br><br>
<dd>Interesting comments Volker! I guess it's all about the perspective
you view it from I suppose. The impact of bad data on law enforcement
investigations can also be waste of valuable time and cost. Except the
cost comes out of of the public purse...<br><br>
<br>
<dd> <br><br>
<dd>Nick Shorey BA(Hons) MSc.<br>
</b><br>
<dd>Senior Policy Advisor | Global Internet Governance<br><br>
<dd>Department for Culture, Media & Sport<br><br>
<dd>HM Government | United Kingdom<br><br>
<dd> <br><br>
<dd>Email:
<a href="mailto:nick.shorey@culture.gov.uk">nick.shorey@culture.gov.uk</a>
<br><br>
<dd>Tel: +44 (0)7710 025 626<br><br>
<dd>Skype: nick.shorey<br><br>
<dd>Twitter: @nickshorey<br><br>
<dd>LinkedIn:
<a href="http://www.linkedin.com/in/nicklinkedin">
www.linkedin.com/in/nicklinkedin</a><br><br>
<dd> <br><br>
<dd>On 6 October 2016 at 17:23, Volker Greimann
<<a href="mailto:vgreimann@key-systems.net">
vgreimann@key-systems.net</a>> wrote:<br><br>
<br>
<dl>
<dd>Hi Greg,<br>
<dl><br>
<dd>Arguments to the contrary tend to look like a Defense of Bad
Data. I can't think of any reasons to defend bad data, unless one
wants a bad database.<br><br>
</dl>
<dd>If you want reasons, here are a few:<br>
<dd>1) Cost<br>
<dd>2) Waste of valuable time<br>
<dd>3) Implementation nightmares<br>
<dd>4) No actual standard that applies worldwide<br>
<dd>5) Legacy data from legacy sources<br>
<dd>6) Customer service nightmare<br>
<dl><br>
<dd>It's reasonable to strive for perfectly accurate data, but accept
that one will never get there. There should be commercially
reasonable and proportionate methods to get as close as practically
possible.<br><br>
</dl>
<dd>One can strive for anything, but it may never be achieved, consuming
valuable ressources on the way. How many people died trying to reach the
south pole, the north pole, the peak of the Matterhorn, before someone
made it. While that first one to make is famous now, consider the loss of
life and ressources wasted we spent getting there.<br>
<dl><br>
<dd>We have not (in this group) discussed data migration, but assuming a
Garbage In, Garbage Out approach doesn't seem reasonable. Whether
all the data is validated before migration, or just validated as part of
a normal validation cycle, it needs be validated.<br><br>
</dl>
<dd>Existing data in is the only feasible solution if you want a
manageable transition process.<br>
<dd>As for validation by the road, before designing a process we should
define who is going to have to implement it, process it, deal with user
complaints, pay for it, etc. What is better data worth to those who have
to pay for it? Are those that benefit from better data going to finance
it (including all associated costs)? If so, let's talk....<br><br>
<dd>Best,<br>
<dd>Volker<br><br>
<dd> <br>
<dl><br>
<dd> <br><br>
<dd>On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels
<<a href="mailto:carlton.samuels@gmail.com">
carlton.samuels@gmail.com</a>> wrote:<br><br>
<br>
<dl>
<dd>+1.<br><br>
<dd> <br><br>
<dd>Not to make too fine a point of it. But the EWG was tasked to
re-imagine an RDS. If this PDP is tasked to build on the works of
EWG maybe it'd be useful to re-visit certain ideas we now hold as
verities.<br><br>
<dd> <br><br>
<dd>-Carlton <br><br>
<br><br>
<dd>==============================<br>
<dd>Carlton A Samuels</i><br>
<dd>Mobile: <a href="tel:876-818-1799">876-818-1799</a><br>
<dd>Strategy, Planning, Governance, Assessment & Turnaround</i><br>
<dd>=============================<br><br>
<dd> <br><br>
<dd>On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche
<<a href="mailto:h.raiche@internode.on.net">
h.raiche@internode.on.net</a>> wrote:<br><br>
<br>
<dl>
<dd>Folks <br><br>
<dd> <br><br>
<dd>Maybe we need to back up a bit and go back to the Charter and what we
are supposed to be doing. Let me quote directly from it:<br><br>
<dd> <br><br>
<dd>First - background: Quoting the Charter on the Board decision to
launch this PDP:<br><br>
<dd> <br><br>
<dd>On 26 May, 2015, the ICANN Board passed a resolution adopting that
Process Framework and reaffirming its 2012 request for a Board -
initiated PDP to define the purpose of collecting, maintaining and
providing access to gTLD registration data, and to consider safeguards
for protecting data, using the recommendations in the EWG’s Final
Report as an input to, and, if appropriate, as the foundation for a new
gTLD policy<br>
</i><br>
<br><br>
<br>
<dd>Later - what The Charter tasked this Working Group with:<br><br>
<br><br>
<br>
<dd>As part of its Phase 1 deliberations, the PDP WG should work to reach
consensus recommendations by considering, at a minimum, the following
complex and inter-related questions:<br>
</i><br>
<dd> Users/Purposes: Who should have access to gTLD registration data
and why?<br>
</i><br>
<dd> Gated Access: What steps should be taken to control data access
for each user/purpose?<br>
</i><br>
<dd> Data Accuracy: What steps should be taken to improve data
accuracy?<br>
</i><br>
<dd> Data Elements: What data should be collected, stored, and
disclosed?<br>
</i><br>
<dd> Privacy: What steps are needed to protect data and privacy?<br>
</i><br>
<dd> Coexistence: What steps should be taken to enable next-generation
RDS coexistence with and replacement of the legacy WHOIS system?<br>
</i><br>
<dd>Compliance: What steps are needed to enforce these policies?<br>
</i><br>
<dd> System Model:What system requirements must be satisfied by any
next-generation RDS implementation?<br>
</i><br>
<dd> Cost: What costs will be incurred and how must they be
covered?<br>
</i><br>
<dd> Benefits: What benefits will be achieved and how will they be
measured?<br>
</i><br>
<dd> Risks: What risks do stakeholders face and how will they be
reconciled?<br>
</i><br><br>
<br><br>
<dd>So accuracy’s there - along with a lot of other issues. That is not
saying that accuracy is not covered in existing requirements on
registries/registrars. But it is giving a broader meaning to RDS -
i.e., it’s not just about collection, maintenance and access to data;
it’s also about safeguards, etc - using the EWG work.<br><br>
<dd> <br><br>
<dd>So thanks Rob. It’s a bit premature to rule issues out when
they are well and truly on our table.<br><br>
<br><br>
<br>
<dd>Holly<br><br>
<br><br>
<br><br>
<br><br>
<dd>On 6 Oct 2016, at 6:37 am, Rod Rasmussen
<<a href="mailto:rrasmussen@infoblox.com">rrasmussen@infoblox.com</a>
> wrote:<br><br>
<dd> <br>
<dl><br>
<dd>Folks, <br><br>
<dd> <br><br>
<dd>Gotta chime in here, since the EWG provided a lot of thinking on this
issue. If you haven’t already, please review the EWG report sections on
data accuracy and also the concept of data validators and their
relationship to the RDS. For example, I would note that a
well-provisioned RDS would be able to provide some sort of validation
checks against existing data in the use case of trying to prevent
impersonation (a form of accuracy) of an existing registrant (a big brand
like Facebook for instance). Another concept we found very
important in the EWG is the idea of creating a contact data set tied to a
contact ID that is portable between registrars and registries. This
provides for the purpose-based contacts we talk about at great length in
the report. It also is key for addressing some of the fundamental
operational issues that lead to inaccurate, out-of-date data at various
registrars. If you have a change in your contact information (a new
e-mail for instance) and hold multiple roles in conjunction with many
domains, you have a real challenge making updates throughout the universe
of your domain names. Using a data validator and then acting via
the RDS, when you make a change to your contact info, that automatically
can be reflected in all domains you are associated with and thus improve
accuracy tremendously. Those are just a couple examples of how an
RDS can be involved in dealing with accuracy issues and represent many of
the concepts you can address once you look beyond the current paradigm of
registrar controlled contact information anchored specifically to
individual domain names. Accuracy in the “generic” system
(including registries, registrars, RDS, validators, some other group we
haven’t thought of yet) is definitely in-scope. How that is done
can take many forms and could have different roles played by different
participants in the entire ecosystem. <br><br>
<dd> <br><br>
<dd>Cheers,<br><br>
<dd> <br><br>
<dd>Rod<br><br>
<dd> <br>
<dl><br>
<dd>On Oct 5, 2016, at 10:36 AM,
<a href="mailto:benny@nordreg.se">benny@nordreg.se</a> wrote:<br><br>
<dd> <br><br>
<dd>But the data accuracy can’t be done in RDS, the accuracy is done on
a registrar level when collecting data.<br><br>
<dd>RDS shall under no circumstances alter any information received from
registry / registrars and showing any different info than what is
collected on that level.<br><br>
<dd> <br><br>
<dd>WG can look at what accuracy they want registrars to do yes, but RDS
doesn’t do anything.<br><br>
<dd> <br><br>
<dd>--<br><br>
<dd>Med vänliga hälsningar / Kind Regards / Med vennlig hilsen<br><br>
<br>
<dd>Benny Samuelsen<br>
<dd>Registry Manager - Domainexpert<br><br>
<dd>Nordreg AB - ICANN accredited registrar<br><br>
<dd>IANA-ID: 638<br><br>
<dd>Phone: <a href="tel:%2B46.42197080">+46.42197080</a><br>
<dd>Direct: <a href="tel:%2B47.32260201">+47.32260201</a><br>
<dd>Mobile: <a href="tel:%2B47.40410200">+47.40410200</a><br><br>
<dd> <br><br>
<dd>From:
</b><<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
gnso-rds-pdp-wg-bounces@icann.org</a>> on behalf of "Metalitz,
Steven" <<a href="mailto:met@msk.com">met@msk.com</a>><br>
<dd>Date: </b>Wednesday, 5 October 2016 at 19:32<br>
<dd>To: </b>'Marika Konings'
<<a href="mailto:marika.konings@icann.org">marika.konings@icann.org</a>
>, Volker Greimann
<<a href="mailto:vgreimann@key-systems.net">
vgreimann@key-systems.net</a>>,
"<a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a>"
<<a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a>><br>
<dd>Subject: </b>Re: [gnso-rds-pdp-wg] For your review - updated RDS
Statement of Purpose<br><br>
<dd> <br><br>
<dd>Volker, what is the basis for your assertion that “data will be
presented "as is" in this system, with no<br><br>
<dd>presumption of any prior cleanup work”?<br><br>
<dd> <br><br>
<dd>That statement will be true if we ultimately conclude that the
current system is adequate and that we do not recommend establishment of
a new RDS. However, if we do recommend a new system, then
improvements to data accuracy are very much on the table, as the charter
provision quoted by Marika indicates. <br><br>
<dd> <br><br>
<dd>Steve Metalitz <br><br>
<dd> <br><br>
<dd> <br><br>
<dd>From:</b>
<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
gnso-rds-pdp-wg-bounces@icann.org</a>
[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] On Behalf Of </b>Marika
Konings<br>
<dd>Sent:</b> Wednesday, October 05, 2016 12:53 PM<br>
<dd>To:</b> Volker Greimann;
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br>
<dd>Subject:</b> Re: [gnso-rds-pdp-wg] For your review - updated RDS
Statement of Purpose<br><br>
<dd> <br><br>
<dd>Volker, please note that the PDP WG Charter (see
<a href="https://community.icann.org/x/E4xlAw">
https://community.icann.org/x/E4xlAw</a>) includes the following
question:<br><br>
<dd> <br>
</b><br>
<dd>As part of its Phase 1 deliberations, </b>the PDP WG should work to
reach consensus recommendations by considering, at a minimum</b>, the
following complex and inter-related questions:<br>
</i><br>
<dd>(..)<br>
</i><br>
<dd>
·
Data Accuracy: </b>What steps should be taken to improve data
accuracy?<br>
</i><br>
<dd>()<br>
</i>
<dd>> <br><br>
<dd> <br><br>
<dd>Best regards,<br><br>
<dd> <br><br>
<dd>Marika<br><br>
<dd> <br><br>
<dd>On 05/10/16 05:58,
"<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20Volker%20Greimann">
gnso-rds-pdp-wg-bounces@icann.org on behalf of Volker Greimann</a>"
<<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org%20on%20behalf%20of%20vgreimann@key-systems.net">
gnso-rds-pdp-wg-bounces@icann.org on behalf of
vgreimann@key-systems.net</a>> wrote:<br><br>
<dd> <br><br>
<dd> I would move to strike all references to data
quality altogether from<br><br>
<dd> this document, e.g. "current",
"accurate" etc.<br><br>
<dd> These are already required by existing policies
and agreements and do<br><br>
<dd> not have to be referenced again at this point. We
should focus on having<br><br>
<dd> to reflect the data as provided by the RNH at this
stage, not make any<br><br>
<dd> presumptions about its quality.<br><br>
<dd> <br><br>
<dd> After all, data will be presented "as
is" in this system, with no<br><br>
<dd> presumption of any prior cleanup work.<br><br>
<dd> <br><br>
<dd> Best,<br><br>
<dd> Volker<br><br>
<dd> <br><br>
<dd> >> THE purpose of the "Registration
Data Service" (hereafter referred to<br><br>
<dd> >> as<br><br>
<dd> >> "RDS") is to manage authorised
parties' access to information about<br><br>
<dd> >> [gTLD Domain Names, gTLD Nameservers,
gTLD Registries and gTLD<br><br>
<dd> >> Registrars]<br><br>
<dd> >><br><br>
<dd> >> Purpose 3(a/b) are possible use cases,
not Purposes as such<br><br>
<dd> >><br><br>
<dd> >> "Accurate" is definitely not a
term to use if we ever expect to finish<br><br>
<dd> >> - "Current"
would be more accurate (sic) / appropriate.<br><br>
<dd> > Agreed, with one minor suggestion:<br><br>
<dd> ><br><br>
<dd> > "access to information about generic
top-level domain registries, registrars, names, and name
servers."<br><br>
<dd> ><br><br>
<dd> > Scott<br><br>
<dd> >
_______________________________________________<br><br>
<dd> > gnso-rds-pdp-wg mailing list<br><br>
<dd> >
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br><br>
<dd> >
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br>
<dd> <br><br>
<dd> -- <br><br>
<dd> Bei weiteren Fragen stehen wir Ihnen gerne zur
Verfügung.<br><br>
<dd> <br><br>
<dd> Mit freundlichen Grüßen,<br><br>
<dd> <br><br>
<dd> Volker A. Greimann<br><br>
<dd> - Rechtsabteilung -<br><br>
<dd> <br><br>
<dd> Key-Systems GmbH<br><br>
<dd> Im Oberen Werk 1<br><br>
<dd> 66386 St. Ingbert<br><br>
<dd> Tel.:
<a href="tel:%2B49%20%280%29%206894%20-%209396%20901">+49 (0) 6894 - 9396
901</a><br><br>
<dd> Fax.:
<a href="tel:%2B49%20%280%29%206894%20-%209396%20851">+49 (0) 6894 - 9396
851</a><br><br>
<dd> Email:
<a href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
<br><br>
<dd> <br><br>
<dd> Web:
<a href="http://www.key-systems.net/">www.key-systems.net</a> /
<a href="http://www.rrpproxy.net/">www.RRPproxy.net</a><br><br>
<dd>
<a href="http://www.domaindiscount24.com/">www.domaindiscount24.com</a> /
<a href="http://www.brandshelter.com/" eudora="autourl">
www.BrandShelter.com</a><br><br>
<dd> <br><br>
<dd> Folgen Sie uns bei Twitter oder werden Sie unser
Fan bei Facebook:<br><br>
<dd>
<a href="http://www.facebook.com/KeySystems">
www.facebook.com/KeySystems</a><br><br>
<dd>
<a href="http://www.twitter.com/key_systems" eudora="autourl">
www.twitter.com/key_systems</a><br><br>
<dd> <br><br>
<dd> Geschäftsführer: Alexander Siffrin<br><br>
<dd> Handelsregister Nr.: HR B 18835 -
Saarbruecken<br><br>
<dd> Umsatzsteuer ID.: DE211006534<br><br>
<dd> <br><br>
<dd> Member of the KEYDRIVE GROUP<br><br>
<dd>
<a href="http://www.keydrive.lu/">www.keydrive.lu</a><br><br>
<dd> <br><br>
<dd> 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.<br><br>
<dd> <br><br>
<dd>
--------------------------------------------<br><br>
<dd> <br><br>
<dd> Should you have any further questions, please do
not hesitate to contact us.<br><br>
<dd> <br><br>
<dd> Best regards,<br><br>
<dd> <br><br>
<dd> Volker A. Greimann<br><br>
<dd> - legal department -<br><br>
<dd> <br><br>
<dd> Key-Systems GmbH<br><br>
<dd> Im Oberen Werk 1<br><br>
<dd> 66386 St. Ingbert<br><br>
<dd> Tel.:
<a href="tel:%2B49%20%280%29%206894%20-%209396%20901">+49 (0) 6894 - 9396
901</a><br><br>
<dd> Fax.:
<a href="tel:%2B49%20%280%29%206894%20-%209396%20851">+49 (0) 6894 - 9396
851</a><br><br>
<dd> Email:
<a href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
<br><br>
<dd> <br><br>
<dd> Web:
<a href="http://www.key-systems.net/">www.key-systems.net</a> /
<a href="http://www.rrpproxy.net/">www.RRPproxy.net</a><br><br>
<dd>
<a href="http://www.domaindiscount24.com/">www.domaindiscount24.com</a> /
<a href="http://www.brandshelter.com/" eudora="autourl">
www.BrandShelter.com</a><br><br>
<dd> <br><br>
<dd> Follow us on Twitter or join our fan community on
Facebook and stay updated:<br><br>
<dd>
<a href="http://www.facebook.com/KeySystems">
www.facebook.com/KeySystems</a><br><br>
<dd>
<a href="http://www.twitter.com/key_systems" eudora="autourl">
www.twitter.com/key_systems</a><br><br>
<dd> <br><br>
<dd> CEO: Alexander Siffrin<br><br>
<dd> Registration No.: HR B 18835 -
Saarbruecken<br><br>
<dd> V.A.T. ID.: DE211006534<br><br>
<dd> <br><br>
<dd> Member of the KEYDRIVE GROUP<br><br>
<dd>
<a href="http://www.keydrive.lu/">www.keydrive.lu</a><br><br>
<dd> <br><br>
<dd> 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.<br><br>
<dd> <br><br>
<dd> <br><br>
<dd> <br><br>
<dd>
_______________________________________________<br><br>
<dd> gnso-rds-pdp-wg mailing list<br><br>
<dd>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br>
<dd> <br><br>
<dd>_______________________________________________<br>
<dd>gnso-rds-pdp-wg mailing list<br>
<dd><a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br>
</dl>
<dd> <br><br>
<dd>_______________________________________________<br>
<dd>gnso-rds-pdp-wg mailing list<br>
<dd><a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br>
</dl>
<dd> <br><br>
<br>
<dd>_______________________________________________<br>
<dd>gnso-rds-pdp-wg mailing list<br>
<dd><a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br>
</dl>
<dd> <br><br>
<br>
<dd>_______________________________________________<br>
<dd>gnso-rds-pdp-wg mailing list<br>
<dd><a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br>
</dl>
<dd> <br><br>
<br><br>
<br><br>
<dd><pre>_______________________________________________</pre><br><br>
<dd><pre>gnso-rds-pdp-wg mailing list</pre><br><br>
<dd><pre><a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a></pre><br><br>
<dd><pre>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre><br>
</dl>
<dd> <br><br>
<dd><pre>-- </pre><br><br>
<dd><pre>Bei weiteren Fragen stehen wir Ihnen gerne zur
Verfügung.</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Mit freundlichen Grüßen,</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Volker A. Greimann</pre><br><br>
<dd><pre>- Rechtsabteilung -</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Key-Systems GmbH</pre><br><br>
<dd><pre>Im Oberen Werk 1</pre><br><br>
<dd><pre>66386 St. Ingbert</pre><br><br>
<dd><pre>Tel.: <a href="tel:%2B49%20%280%29%206894%20-%209396%20901">+49
(0) 6894 - 9396 901</a></pre><br><br>
<dd><pre>Fax.: <a href="tel:%2B49%20%280%29%206894%20-%209396%20851">+49
(0) 6894 - 9396 851</a></pre><br><br>
<dd><pre>Email:
<a href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Web:
<a href="http://www.key-systems.net/">www.key-systems.net</a> /
<a href="http://www.rrpproxy.net/" eudora="autourl">www.RRPproxy.net</a>
</pre><br><br>
<dd><pre><a href="http://www.domaindiscount24.com/">
www.domaindiscount24.com</a> /
<a href="http://www.brandshelter.com/" eudora="autourl">
www.BrandShelter.com</a></pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Folgen Sie uns bei Twitter oder werden Sie unser Fan bei
Facebook:</pre><br><br>
<dd><pre><a href="http://www.facebook.com/KeySystems">
www.facebook.com/KeySystems</a></pre><br><br>
<dd><pre><a href="http://www.twitter.com/key_systems" eudora="autourl">
www.twitter.com/key_systems</a></pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Geschäftsführer: Alexander Siffrin</pre><br><br>
<dd><pre>Handelsregister Nr.: HR B 18835 - Saarbruecken </pre><br><br>
<dd><pre>Umsatzsteuer ID.: DE211006534</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Member of the KEYDRIVE GROUP</pre><br><br>
<dd><pre><a href="http://www.keydrive.lu/">www.keydrive.lu</a>
</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>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.</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>--------------------------------------------</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Should you have any further questions, please do not hesitate to
contact us.</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Best regards,</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Volker A. Greimann</pre><br><br>
<dd><pre>- legal department -</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Key-Systems GmbH</pre><br><br>
<dd><pre>Im Oberen Werk 1</pre><br><br>
<dd><pre>66386 St. Ingbert</pre><br><br>
<dd><pre>Tel.: <a href="tel:%2B49%20%280%29%206894%20-%209396%20901">+49
(0) 6894 - 9396 901</a></pre><br><br>
<dd><pre>Fax.: <a href="tel:%2B49%20%280%29%206894%20-%209396%20851">+49
(0) 6894 - 9396 851</a></pre><br><br>
<dd><pre>Email:
<a href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Web:
<a href="http://www.key-systems.net/">www.key-systems.net</a> /
<a href="http://www.rrpproxy.net/" eudora="autourl">www.RRPproxy.net</a>
</pre><br><br>
<dd><pre><a href="http://www.domaindiscount24.com/">
www.domaindiscount24.com</a> /
<a href="http://www.brandshelter.com/" eudora="autourl">
www.BrandShelter.com</a></pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Follow us on Twitter or join our fan community on Facebook and
stay updated:</pre><br><br>
<dd><pre><a href="http://www.facebook.com/KeySystems">
www.facebook.com/KeySystems</a></pre><br><br>
<dd><pre><a href="http://www.twitter.com/key_systems" eudora="autourl">
www.twitter.com/key_systems</a></pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>CEO: Alexander Siffrin</pre><br><br>
<dd><pre>Registration No.: HR B 18835 - Saarbruecken </pre><br><br>
<dd><pre>V.A.T. ID.: DE211006534</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>Member of the KEYDRIVE GROUP</pre><br><br>
<dd><pre><a href="http://www.keydrive.lu/">www.keydrive.lu</a>
</pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre>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.</pre><br>
<dd><pre> </pre><br><br>
<dd><pre> </pre><br><br>
<dd><pre> </pre><br><br>
<dd>_______________________________________________ gnso-rds-pdp-wg
mailing list
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br>
</dl>
<dd> <br><br>
<dd>_______________________________________________ gnso-rds-pdp-wg
mailing list
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br>
<br>
<dd><pre>_______________________________________________</pre><br><br>
<dd><pre>gnso-rds-pdp-wg mailing list</pre><br><br>
<dd><pre><a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a></pre><br><br>
<dd><pre>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre><br>
</dl>
<dd> <br>
</blockquote>
</dl>
<dd>_______________________________________________ gnso-rds-pdp-wg
mailing list
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a> <br><br>
</dl>_______________________________________________ gnso-rds-pdp-wg
mailing list
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></blockquote>
</blockquote>Content-Type: text/plain; charset="us-ascii"<br>
Content-Transfer-Encoding: 7bit<br>
Content-Disposition: inline<br>
X-Microsoft-Exchange-Diagnostics:<br>
<x-tab> </x-tab>
1;DM5PR03MB2714;9:hkNhvlOvFsYxQ1pp43Ml6KkLx8C96LgnO+RBWv02aNRTWJ6pleWnSxqUBxU8/Okp39l1SudWSL2MtPsLkJaKANhWvy+zW3FgkKIEqT46rrXWHfA5TgKiRe0JlV59h0YUXgGMxc3jIbJaRcwpTi7IQ6k16JliXX07xSVMhGm6dO2iW+zz+X1bDN++4OdQQ/bpbOr30w7KdTqntJ9nDjk0IDp5yEscQGvK1/+2657iPLHWgh1M9TKGurpyB6sU72WSV7eq9aCcJEpigFnRxg1m8HUsaaPkocDa7Nc2d3gtkl2R6G6CTvX+/HtEmI2BiMn4Z1EeccMX3YQxNHy2ZFo02C7qrWRCD6JERnkmPs0sbsV7A7Qfl7wNNFYThQfZNz1sXyOOTlB/QBAwCcRwuPpPRHR4Fei/zhEYc2szAwLHc+JoyXfo406A3Gda+XbfT02f<br>
X-Microsoft-Antispam-Mailbox-Delivery:<br>
<x-tab> </x-tab>
ex:0;auth:0;dest:I;ENG:(20160514016)(520000050)(520002050)(750028);<br>
<br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
gnso-rds-pdp-wg@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></blockquote>
</body>
</html>