[gnso-rds-pdp-wg] What we need & doing our job (was Re: ICANN Meetings/Conversations ...)

[Andrew Sullivan]

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