[gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker Greimann
vgreimann at key-systems.net
Fri Oct 7 10:48:11 UTC 2016
>> Law enforcement has a goal of catching criminals. They actually
>> succeed quite often. The time, cost and level of success depend on
>> the tools available.
Not all tools are legal though. The fruit of the forbidden tree prevents
all available tools from being used.
>>
>> Criminals have a goal of ripping people off. Online crime undermines
>> the security of the Internet and reduces consumer/end-user trust and
>> confidence in the Internet.
Depends. There may be cartain criminal uses that are beneficial to more
people than detrimental. Opposing the government or publishing secret
information may be a criminal act, but stell be in the public benefit..
In those "Robin Hood" cases, the "crime" does not undermine consumer
trust in the least bit.
>>
>> Maintaining the security of the Internet and trust in the Internet is
>> a critical part of ICANN's mission.
Agreed.
>> Our policy recommendations have to support ICANN's mission.
Right.
>>
>> The direction in which we need to go seems fairly clear.
Not necessarily as this argument chain contains a logical fallacy.
To borrow from the classic Monty Python sketch the logician:
/"Given the premise, 'all fish live underwater' and 'all mackerel are
fish', some people will conclude, not that 'all mackerel live
underwater', but that 'if she buys kippers it will not rain', or that
'trout live in trees'."/
By your logic, ICANN and by extention the contracted parties would have
to become the ultimate internet policeman, preventing crime wherever it
looks. That however would be so far outside the scope of ICANNs mission ...
By your logic, we would have to set up a PDP to prevent anything that
could perceivably harm consumer/end-user trust and confidence in the
Internet, such as transactions gone wrong, shipping failures for
consumer purchases or even websites with questionable content.
Maintaining consumer/end-user trust and confidence in the Internet is
important, but as far as it concerns ICANNs mission, its role should
remain limited to:
1) Ensuring trust and confidence by making sure the internet technically
functions and technical provisions are in place to prevent technical abuse
2) Ensuring trust and confidence by enforcing its agreements (which it does)
Best,
Volker
>>
>> Greg Shatan
>>
>>
>>
>>
>> On Thursday, October 6, 2016, Stephanie Perrin
>> <stephanie.perrin at mail.utoronto.ca
>> <mailto:stephanie.perrin at mail.utoronto.ca>> wrote:
>>
>> Not at all, ordinary people make mistakes all the time. However,
>> rarely would this kind of mistake render the person/organization
>> un-contactable, which it seems to me is the evil we are trying to
>> avoid with bad data. On the other hand, criminals have a goal of
>> being untraceable, so will continue to make sure they are not
>> located, right?
>>
>> SP
>>
>>
>> On 2016-10-06 19:20, Mark Svancarek wrote:
>>>
>>> There seems to be a presumption that bad data is caused entirely
>>> by bad people.
>>>
>>> Do we actually have data showing which fraction of bad data is
>>> created with criminal intent, and which fraction is just people
>>> being lazy or careless and then never being held accountable by
>>> the data actually being verified?
>>>
>>> *From:*gnso-rds-pdp-wg-bounces at icann.org
>>> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces at icann.org');>
>>> [mailto:gnso-rds-pdp-wg-bounces at icann.org
>>> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces at icann.org');>]
>>> *On Behalf Of *Stephanie Perrin
>>> *Sent:* Thursday, October 6, 2016 3:09 PM
>>> *To:* gnso-rds-pdp-wg at icann.org
>>> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg at icann.org');>
>>> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS
>>> Statement of Purpose
>>>
>>> I agree with those pushing back on including a commitment to
>>> accuracy in this statement of purpose. I think there are a
>>> number of sound reasons for this. Those of us who push back are
>>> not advocating for bad data, that would be silly. What we are
>>> addressing is the futility of attempting to get the criminal
>>> element to put good data in their registration data. If we
>>> force them, we drive ID theft. Here are a few of my reasons:
>>>
>>> 1. Governments actually do not usually invest taxpayers money
>>> verifying citizen data, they provide penalties for having
>>> inaccurate data and leave it at that. Verifying address and
>>> phone number, given the mobility of the population in the
>>> countries I am familiar with from my past government service
>>> (US, Canada, Australia, New Zealand, and UK) is expensive and
>>> there is very little way to enforce it. This being the case,
>>> why would we force ICANN to do this? The cost inevitably would
>>> fall on the Registrars and registries, and be passed on to the
>>> end users.
>>>
>>> 2. As mentioned above, any pressure to improve data quality can
>>> hardly be expected to get criminals to give their accurate data,
>>> it will drive them to steal good data.
>>>
>>> 3. The vast majority of people are actually honest. I do
>>> realize that there is a high volume of cybercrime, but
>>> penalizing the majority of end users for the actions of a few
>>> (even if those actions result in a high volume of phishing and
>>> malware etc) is not good policy. There are other ways to catch
>>> and dump bad domains. Prosecution of malfeasant registrants
>>> remains a problem, but frankly how many can be prosecuted across
>>> borders anyway?
>>>
>>> 4. We do have questions about accuracy that we need to address,
>>> according to our charter. The purpose of this purpose statement
>>> is to boil down our business requirements for the activity in
>>> which we are engaged. While many actors want more accurate
>>> data, how to get that accuracy is so open to question that I
>>> regard its inclusion in the statement of purpose as setting
>>> impossible goals. I would be happy to revise this sentence as
>>> follows:
>>>
>>> To enable release of accurate gTLD registration data that may
>>> not otherwise be publicly available, under specific and explicit
>>> policy-defined conditions Change to
>>>
>>> To enable release of gTLD registration data that may not
>>> otherwise be publicly available under specific conditions
>>> defined by policy, and to develop mechanisms to encourage
>>> greater accuracy of data.
>>>
>>> Stephanie Perrin
>>>
>>> On 2016-10-06 16:48, Chris Pelling wrote:
>>>
>>> Hi Nick,
>>>
>>> I would actually concur with Volker. I see your point but,
>>> can I ask a question, the data collected cannot be proven to
>>> any certainty because we have nothing as the
>>> registry/registrar community to "check" it against. Simply
>>> checking say the address against a city, against a State,
>>> against a postal/zip code then country isnt proving the
>>> registrant data is correct, its simply proving that the
>>> registrant can open a phone book and pick an address out.
>>>
>>> Until tools are created to prove that registrant is actually
>>> at address X, accuracy is a rather moot point.
>>>
>>> I agree with your point about law enforcement and bad data
>>> being a cost to the public purse, but until the governments
>>> can get together and work out a solution for the data to be
>>> verified there is little anyone can do.
>>>
>>> Registrant giving fake address = bad data
>>>
>>> Registrant giving correct address of neighbour = bad data
>>>
>>> Registrant giving old address where previously lived = bad
>>> data - but at least it could be validated against old
>>> correct data and cross checked
>>>
>>> This list could be endless :
>>>
>>> Registrant giving correct data = good, verifiable. Maybe the
>>> governments can work out a solution to being able to verify
>>> their citizens data.
>>>
>>> I would love to find a solution that is workable and
>>> commercially viable, the governments and LEA can then use
>>> the data with some surety to its worthiness - although this
>>> is a totally separate topic, I would like to sit down and
>>> discuss it further - the governments getting together and
>>> helping this work.
>>>
>>> Just a thought.
>>>
>>> Kind regards,
>>>
>>> Chris
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From: *"Nick Shorey" <nick.shorey at culture.gov.uk>
>>> <javascript:_e(%7B%7D,'cvml','nick.shorey at culture.gov.uk');>
>>> *To: *"Volker Greimann" <vgreimann at key-systems.net>
>>> <javascript:_e(%7B%7D,'cvml','vgreimann at key-systems.net');>
>>> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
>>> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg at icann.org');>
>>> *Sent: *Thursday, 6 October, 2016 17:38:55
>>> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated
>>> RDS Statement of Purpose
>>>
>>> Interesting comments Volker! I guess it's all about the
>>> perspective you view it from I suppose. The impact of bad
>>> data on law enforcement investigations can also be waste of
>>> valuable time and cost. Except the cost comes out of of the
>>> public purse...
>>>
>>>
>>> *Nick Shorey BA(Hons) MSc.*
>>>
>>> Senior Policy Advisor | Global Internet Governance
>>>
>>> Department for Culture, Media & Sport
>>>
>>> HM Government | United Kingdom
>>>
>>> Email: nick.shorey at culture.gov.uk
>>> <javascript:_e(%7B%7D,'cvml','nick.shorey at culture.gov.uk');>
>>>
>>> Tel: +44 (0)7710 025 626
>>>
>>> Skype: nick.shorey
>>>
>>> Twitter: @nickshorey
>>>
>>> LinkedIn: www.linkedin.com/in/nicklinkedin
>>> <http://www.linkedin.com/in/nicklinkedin>
>>>
>>> On 6 October 2016 at 17:23, Volker Greimann
>>> <vgreimann at key-systems.net
>>> <javascript:_e(%7B%7D,'cvml','vgreimann at key-systems.net');>>
>>> wrote:
>>>
>>> Hi Greg,
>>>
>>> Arguments to the contrary tend to look like a
>>> Defense of Bad Data. I can't think of any reasons
>>> to defend bad data, unless one wants a bad database.
>>>
>>> If you want reasons, here are a few:
>>> 1) Cost
>>> 2) Waste of valuable time
>>> 3) Implementation nightmares
>>> 4) No actual standard that applies worldwide
>>> 5) Legacy data from legacy sources
>>> 6) Customer service nightmare
>>>
>>> It's reasonable to strive for perfectly accurate
>>> data, but accept that one will never get there.
>>> There should be commercially reasonable and
>>> proportionate methods to get as close as practically
>>> possible.
>>>
>>> One can strive for anything, but it may never be
>>> achieved, consuming valuable ressources on the way. How
>>> many people died trying to reach the south pole, the
>>> north pole, the peak of the Matterhorn, before someone
>>> made it. While that first one to make is famous now,
>>> consider the loss of life and ressources wasted we spent
>>> getting there.
>>>
>>> We have not (in this group) discussed data
>>> migration, but assuming a Garbage In, Garbage Out
>>> approach doesn't seem reasonable. Whether all the
>>> data is validated before migration, or just
>>> validated as part of a normal validation cycle, it
>>> needs be validated.
>>>
>>> Existing data in is the only feasible solution if you
>>> want a manageable transition process.
>>> As for validation by the road, before designing a
>>> process we should define who is going to have to
>>> implement it, process it, deal with user complaints, pay
>>> for it, etc. What is better data worth to those who have
>>> to pay for it? Are those that benefit from better data
>>> going to finance it (including all associated costs)? If
>>> so, let's talk....
>>>
>>> Best,
>>> Volker
>>>
>>> On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels
>>> <carlton.samuels at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','carlton.samuels at gmail.com');>>
>>> wrote:
>>>
>>> +1.
>>>
>>> Not to make too fine a point of it. But the EWG
>>> was tasked to re-imagine an RDS. If this PDP is
>>> tasked to build on the works of EWG maybe it'd
>>> be useful to re-visit certain ideas we now hold
>>> as verities.
>>>
>>> -Carlton
>>>
>>>
>>>
>>> ==============================
>>> /Carlton A Samuels/
>>> /Mobile: 876-818-1799 <tel:876-818-1799>
>>> //Strategy, Planning, Governance, Assessment &
>>> Turnaround/
>>> =============================
>>>
>>> On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche
>>> <h.raiche at internode.on.net
>>> <javascript:_e(%7B%7D,'cvml','h.raiche at internode.on.net');>>
>>> wrote:
>>>
>>> Folks
>>>
>>> Maybe we need to back up a bit and go back
>>> to the Charter and what we are supposed to
>>> be doing. Let me quote directly from it:
>>>
>>> First - background: Quoting the Charter on
>>> the Board decision to launch this PDP:
>>>
>>> /On 26 May, 2015, the ICANN Board passed
>>> a resolution adopting that Process Framework
>>> and reaffirming its 2012 request for a
>>> Board - initiated PDP to define the purpose
>>> of collecting, maintaining and providing
>>> access to gTLD registration data, and to
>>> consider safeguards for protecting data,
>>> using the recommendations in the EWG’s
>>> Final Report as an input to, and, if
>>> appropriate, as the foundation for a new
>>> gTLD policy/
>>>
>>>
>>>
>>> Later - what The Charter tasked this Working
>>> Group with:
>>>
>>>
>>>
>>> /As part of its Phase 1 deliberations, the
>>> PDP WG should work to reach consensus
>>> recommendations by considering, at a
>>> minimum, the following complex and
>>> inter-related questions:/
>>>
>>> /// Users/Purposes: Who should have access
>>> to gTLD registration data and why?/
>>>
>>> /// Gated Access: What steps should be
>>> taken to control data access for each
>>> user/purpose?/
>>>
>>> /// Data Accuracy: What steps should be
>>> taken to improve data accuracy?/
>>>
>>> /// Data Elements: What data should be
>>> collected, stored, and disclosed?/
>>>
>>> /// Privacy: What steps are needed to
>>> protect data and privacy?/
>>>
>>> /// Coexistence: What steps should be taken
>>> to enable next-generation RDS coexistence
>>> with and replacement of the legacy WHOIS
>>> system?/
>>>
>>> ///Compliance: What steps are needed to
>>> enforce these policies?/
>>>
>>> /// System Model:What system requirements
>>> must be satisfied by any next-generation
>>> RDS implementation?/
>>>
>>> /// Cost: What costs will be incurred and
>>> how must they be covered?/
>>>
>>> /// Benefits: What benefits will be
>>> achieved and how will they be measured?/
>>>
>>> /// Risks: What risks do stakeholders face
>>> and how will they be reconciled?/
>>>
>>>
>>>
>>> So accuracy’s there - along with a lot of
>>> other issues. That is not saying that
>>> accuracy is not covered in existing
>>> requirements on registries/registrars. But
>>> it is giving a broader meaning to RDS -
>>> i.e., it’s not just about collection,
>>> maintenance and access to data; it’s also
>>> about safeguards, etc - using the EWG work.
>>>
>>> So thanks Rob. It’s a bit premature to rule
>>> issues out when they are well and truly on
>>> our table.
>>>
>>>
>>>
>>> Holly
>>>
>>>
>>>
>>>
>>>
>>> On 6 Oct 2016, at 6:37 am, Rod Rasmussen
>>> <rrasmussen at infoblox.com
>>> <javascript:_e(%7B%7D,'cvml','rrasmussen at infoblox.com');>>
>>> wrote:
>>>
>>> Folks,
>>>
>>> Gotta chime in here, since the EWG
>>> provided a lot of thinking on this
>>> issue. If you haven’t already, please
>>> review the EWG report sections on data
>>> accuracy and also the concept of data
>>> validators and their relationship to the
>>> RDS. For example, I would note that a
>>> well-provisioned RDS would be able to
>>> provide some sort of validation checks
>>> against existing data in the use case of
>>> trying to prevent impersonation (a form
>>> of accuracy) of an existing registrant
>>> (a big brand like Facebook for
>>> instance). Another concept we found very
>>> important in the EWG is the idea of
>>> creating a contact data set tied to a
>>> contact ID that is portable between
>>> registrars and registries. This provides
>>> for the purpose-based contacts we talk
>>> about at great length in the report. It
>>> also is key for addressing some of the
>>> fundamental operational issues that lead
>>> to inaccurate, out-of-date data at
>>> various registrars. If you have a change
>>> in your contact information (a new
>>> e-mail for instance) and hold multiple
>>> roles in conjunction with many domains,
>>> you have a real challenge making updates
>>> throughout the universe of your domain
>>> names. Using a data validator and then
>>> acting via the RDS, when you make a
>>> change to your contact info, that
>>> automatically can be reflected in all
>>> domains you are associated with and thus
>>> improve accuracy tremendously. Those are
>>> just a couple examples of how an RDS can
>>> be involved in dealing with accuracy
>>> issues and represent many of the
>>> concepts you can address once you look
>>> beyond the current paradigm of registrar
>>> controlled contact information anchored
>>> specifically to individual domain names.
>>> Accuracy in the “generic” system
>>> (including registries, registrars, RDS,
>>> validators, some other group we haven’t
>>> thought of yet) is definitely in-scope.
>>> How that is done can take many forms and
>>> could have different roles played by
>>> different participants in the entire
>>> ecosystem.
>>>
>>> Cheers,
>>>
>>> Rod
>>>
>>> On Oct 5, 2016, at 10:36 AM,
>>> benny at nordreg.se
>>> <javascript:_e(%7B%7D,'cvml','benny at nordreg.se');>
>>> wrote:
>>>
>>> But the data accuracy can’t be done
>>> in RDS, the accuracy is done on a
>>> registrar level when collecting data.
>>>
>>> RDS shall under no circumstances
>>> alter any information received from
>>> registry / registrars and showing
>>> any different info than what is
>>> collected on that level.
>>>
>>> WG can look at what accuracy they
>>> want registrars to do yes, but RDS
>>> doesn’t do anything.
>>>
>>> --
>>>
>>> Med vänliga hälsningar / Kind
>>> Regards / Med vennlig hilsen
>>>
>>>
>>> Benny
>>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20161007/e492966c/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list