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

[Greg Aaron]

Dear Ayden:

“Ignoring a potentially catastrophic outcome” is not something I suggested.  I said that a worst-case scenario does not necessarily dictate what the solution is.  (Otherwise there would be no balancing process needed, and the most restrictive, harsh, and secure solution would automatically be put in place.)

Very different from what you said I said.

All best,
--Greg



From: Ayden Férdeline [mailto:icann at ferdeline.com]
Sent: Monday, August 22, 2016 4:25 PM
To: Greg Aaron <gca at icginc.com>
Cc: Carlton Samuels <carlton.samuels at gmail.com>; Volker Greimann <vgreimann at key-systems.net>; RDS WG <gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] @EXT: RE: Use cases: Fundamental, Incidental, and Theoretical

Greg,

A worst case scenario is not a fantasy. It is a real, possible outcome that justifies taking precautions from the onset of our work. We should not under-estimate these scenarios but prepare for them. I tend to think of risk as a seesaw; it is easy to be ambivalent and to see merit on both sides of the issue, or to think something as though it is very unlikely to happen, but if we ignore a potentially catastrophic outcome we are only asking for trouble and could tip the seesaw out of equilibrium. I would encourage the Working Group to consider Volker and Carlton's suggested approach.

Best wishes,

Ayden

-------- Original Message --------
Subject: Re: [gnso-rds-pdp-wg] @EXT: RE: Use cases: Fundamental, Incidental, and Theoretical
Local Time: August 22, 2016 5:43 PM
UTC Time: August 22, 2016 4:43 PM
From: gca at icginc.com<mailto:gca at icginc.com>
To: carlton.samuels at gmail.com,vgreimann at key-systems.net<mailto:carlton.samuels at gmail.com,vgreimann at key-systems.net>
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>


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
=============================



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