[gnso-rds-pdp-wg] What we need & doing our job (was Re: ICANN Meetings/Conversations ...)
Andrew Sullivan
ajs at anvilwalrusden.com
Sat Sep 23 18:47:22 UTC 2017
Hi,
I apologise that this is a little long, but I'm alarmed at the drift
of this conversation and want to make some principles on which I am
relying crystal clear.
On Sat, Sep 23, 2017 at 09:13:05AM -0400, Sam Lanfranco wrote:
> ICANN’s policies and practices for security and stability of the Internet,
[…]
> The old worry that the ITU, the UN, or some other multilateral organization,
> might “take over” the management and policy development for the security and
> stability of the Internet
[…]
> This does not mean that ICANN should expand its policy remit.
Indeed, and we shouldn't expand it either. ICANN has a tightly
limited role in the "security and stability of the Internet". It has
an important but limited role because it is limited to certain unique
identifier sytems, and not everything else.
Now, there is a reason that we in this PDP need to take into account
the security and stability work that _others_ undertake (as John
Bambenek reminds us only today) and to ensure that the identifier
system for which ICANN-the-community makes policy (the names system)
provides the necessary and adequate support for such activities (and
only that much support). The reason is contained in article I section
1 item 3 of the Bylaws: "Coordinates policy development reasonably and
appropriately related to these technical functions." We need to pay
attention to that, because it limits what we ought to attend to.
This is the reason that I keep trying to probe the relationship
between the SRSes and the RDS: the former at least is very clearly a
distributed system, which is correctly aligned with the architecture
of the Internet. I claim that any RDS that will last more than 10
minutes on the public Internet will also be a distributed system. The
Internet needs to be able to achieve certain thngs using that
distributed RDS database:
1. Provide support for the security practices in technical
standards that depend on domain names. Important among these is
the support needed for X.509 Certificate Authorities who need
certain kinds of data to be able to undertake certain modes of
validation. Also important among these are anti-abuse researchers
and data providers, who provide the necessary data to discurage
the proliferation of malware and to reduce the incidence of spam
and so on -- all in a voluntary-interoperation mode that is
appropriate to how the Internet is designed. This is to do with
the security of the identifier system, because of what the
identifier system is used for (i.e. the purpose of the identifiers
in the first place).
2. Provide support for operators who otherwise do not have
contact or contracts with one another to be able to reach each
other in the event that there is some interoperation problem. The
Internet's architecture depends on distributed management without
a lot of prior contractual relationships. That architecture
depends operators being able to reach each other, which means
exposing certain kinds of reachability data in the event you want
to operate some infrastructure. That of course does not
necessarily mean one's personal data to everyone in the world, but
it does mean that _some_ such reachability data is needed and that
there is but one way to withdraw consent: stop operating such
infrastructure. This goes to the stability of the identifier
system, because if internal threats from it cannot be dealt with
properly then the identifier system will be undermined by people
breaking it. We already see this in some ways, which is part of
what the "universal acceptance" project is about.
3. Provide support for the interaction of the identifier system
with legal systems, whether those be criminal or civil issues.
This is somewhat different than (1) because it often does not go
directly to the issue of operation of the Internet. This still
goes to both the security and stability of the identifier system,
however, because without supporting these needs the identifier
system will come under social, political, and legal attack.
These are basic needs of the system itself, and they cannot be traded
away: anyone who says that these are incompatible with applicable
privacy needs and legislation is either saying that such privacy needs
or legislation (or both) are incompatible with operating Internet
infrastructure, or else is making overlarge claims about what the
privacy needs or legislation (or both) actually entail.
At the same time, we do not need to go beyond the above list, and I
believe that with a little attention to the capabilities of protcols
that actually exist we can provide those necessary features while
requiring a limited disclosure of information and thereby adequately
and appropriately addresses legitimate privacy concerns and
legislative requirements. We can do this in a generalised way,
without reviewing every possible piece of legislation everywhere in
the world.
We, in this PDP WG, are in the fortunate position of knowing what
ICANN's mission actually is, of knowing what the system needs really
are, and of having the authority to put together a proposal for how
the future policy should work in respect of both of those factors. We
all have an interest (at least a personal one) in minimal data
collection and the avoidance of unacceptable disclosures. I think we
are allowing ourselves far too often to be drawn off into issues
beyond our remit.
Therefore, I urge again that we concentrate on the issues at hand. We
do not need to expand the dialogue, worry about bigger policy issues,
or figure out how to make an already-huge set of process problems into
a completely unmanageable one. We have a job, and I say we shoud get
on with it instead of trying to expand it to the Cartesian product of
every possible link among ICANN, policy, privacy, policy-makers, and
the rest of humanity.
Best regards,
A
--
Andrew Sullivan
ajs at anvilwalrusden.com
More information about the gnso-rds-pdp-wg
mailing list