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@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Carlton Samuels
Sent: Monday, August 22, 2016 12:02 PM
To: Volker Greimann <vgreimann@key-systems.net>
Cc: RDS WG <gnso-rds-pdp-wg@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@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.

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

=============================