[gnso-rds-pdp-wg] High level goal (was Re: For WG Review - Redlined Problem Statement)

Gomes, Chuck cgomes at verisign.com
Fri Aug 19 23:26:27 UTC 2016


Also well said Stephanie.

Chuck

From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Stephanie Perrin
Sent: Friday, August 19, 2016 3:23 PM
To: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] High level goal (was Re: For WG Review - Redlined Problem Statement)


+1.  We are never going to resolve the tensions, because the approach to the matter between different groups with different interests is vast.  We need to strike a bargain that seems fair enough for the moment. Detente.  But I don't recommend introducing that word

Stephanie Perrin

On 2016-08-18 18:42, Andrew Sullivan wrote:

Hi,



On Thu, Aug 18, 2016 at 10:18:13PM +0000, Gomes, Chuck wrote:



the WG will have to try to find solutions to mitigate the tensions

among stakeholders with regard to possible RDS requirements and

policies.  In fact, I believe that this is a key point of the overall

problem statement.



I don't think we actually disagree about this, but let me try to put a

different gloss on that and see whether you think it's right.



Our problem is not to resolve the tension among stakeholders or

different parties.  Our problem is to forge a policy that takes into

account those various views, with the understanding that the goal is

ultimately to produce a policy that produces the best outcome for the

Internet (which means also for the constituent networks and the actual

and potential users of them).  One consequence of that understanding

is that we probably should not produce policies that radically empower

one set of views at the overwhelming cost of another, unless the

losing view is itself something that does not contribute to good

outcomes for the Internet.  (So, for instance, it's ok to say that a

view which desires to undermine the end to end principle is one we

simply will not accommodate: its entire goal is to undermine the basis

of internetworking.)



ICANN policies are best when they support and promote the

interoperation of networks that make up the Internet, where those

policies impinge upon the DNS at the levels closest to the root zone.

Some of that policy inevitably interacts with national laws, sub-,

trans-, and inter-national issues in operation of the constituent

networks, and issues that arise at the nexus of protocol operation and

use of those protocols (where the "users" in this case are the entire

class of anyone who wants to use the Internet at the top-most parts of

the DNS).  For that reason, ICANN policies need to reflect those

conditions, which means taking into account the legal and political

realities that affect the Internet wherever it is deployed.  At the

same time, we need to accept and recognise that some legal and

political demands really do represent a threat to the Internet itself,

and such demands (regardless of which legal regime backs them) are not

something that ICANN policy can legitimately accommodate.



Therefore, we set our bar too high if we think we can _resolve_ the

tussle[1].  All we can do is work out a _modus vivendi_ in which some

new stage in the tussle stabilizes for a period.  It seems to me that

we are at a stage in Internet development where everyone acknowledges

that (1) the existing state of affairs is unsatisfying to just about

everyone and (2) the technology has evolved in ways that permit us to

look at desires with fresh eyes and attempt to make new,

medium-term-stable arrangements.



Does that seem close to what you're trying to suggest?



Best regards,



A



[1] http://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf.

In my opinion, anyone who hasn't read that paper and who is

participating in Internet policy development is doing him or herself a

disservice.



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


More information about the gnso-rds-pdp-wg mailing list