[gnso-rds-pdp-wg] @EXT: RE: Use cases: Fundamental, Incidental, and Theoretical

Mon Aug 22 17:28:48 UTC 2016

Volker,

It’s not clear to me that what Greg proposed is the exact opposite of your basic premise but I’ll let Greg comment on that.  I do want to remind everyone though that the 11th question in each of the three phases deals with risks.

Chuck

From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Volker Greimann
Sent: Monday, August 22, 2016 12:58 PM
To: Greg Aaron; Carlton Samuels
Cc: RDS WG
Subject: Re: [gnso-rds-pdp-wg] @EXT: RE: Use cases: Fundamental, Incidental, and Theoretical

Hi Greg,

We are trekking ahead of the pack again, but as this is now a topic:

Our basic premise, in my humble opinion, should be the exact opposite of your proposal:

a) NO data is collected;

b) NO ONE has access to any of the collected data;

c) collected data may not be requested/used for any purpose.

From that basic level (which admittely is so extreme it cannot be our final result) we need to figure out the exceptions to these rules while trying to poke holes into the exceptions to prevent as much abuse as we can think of and then establish mechanisms of review of these exceptions at regular intervals to see if abuse has occurred or additional exceptions may become necessary. This is why we are designing use cases now and that is where your questions would come in.

Anything less will be a system doomed to be abused without limit.

And this would not even enter into the problem of how/where to store the data, how to design access methods and authorization verifications, etc.

To your examples: To drive and/or fly, you need a license and it is regulated how to get one and who may apply for one.

Am 22.08.2016 um 18:43 schrieb Greg Aaron:
No traditional risk analysis starts with the assumption that the worst-case scenario will determines what will be done.  (Otherwise none of us should drive because of the risk of accidents, and none of us should fly, because terrorists.)

Risk analysis tends to follow this outline:

1.      What can happen? (i.e., what can go wrong?)

2.      How likely is it that it will happen?

3.      If it does happen, what are the consequences?

And then choices are made, balancing the various variables. As we have been discussing,  there are various opinions and  concerns among the participants and stakeholders.  At some point those need to be laid out and quantified where possible, so that fact-based decision-making and balancing can be done.

See also SAC061 Recommendation 2: “The ICANN Board should ensure that a formal security risk assessment of the registration data policy be conducted as an input into the Policy Development Process.”  That would happen down the line, when things have progressed further and policy options have are coalesced.

All best,
--Greg

From: gnso-rds-pdp-wg-bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Carlton Samuels
Sent: Monday, August 22, 2016 12:02 PM
To: Volker Greimann <vgreimann at key-systems.net><mailto:vgreimann at key-systems.net>
Cc: RDS WG <gnso-rds-pdp-wg at icann.org><mailto:gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] @EXT: RE: Use cases: Fundamental, Incidental, and Theoretical

On Mon, Aug 22, 2016 at 2:19 AM, Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>> wrote:
Simply put: Anything that can be abused, will be abuse. We therefore need to model our approach on the worst possible actors, not the best.

+1

I cannot see how any other model makes sense in this context.

-Carlton

==============================
Carlton A Samuels
Mobile: 876-818-1799
Strategy, Planning, Governance, Assessment & Turnaround
=============================

--

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<mailto:vgreimann at 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 at key-systems.net<mailto:vgreimann at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160822/c2d9ddbd/attachment.html>