Comments from Andrew Sullivan on CWG proposal

[Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx>]

Grace Abuhamad
Staff Contact
Cross Community Working Group (CWG) on Naming Related Functions 
via email

Dear Ms Abuhamad,

I appreciate the opportunity to submit remarks on the draft proposal
from the Cross Community Working Group (CWG) on Naming Related
Functions.  I have read this proposal with interest, and I thank the
CWG for its work.  I have some comments.  I make these comments in a
personal capacity, and not as a representative of any group or
corporate body.

I have two classes of comment.  First, I will make some comments on
the substance of the proposal.  Second, I will offer some observations
on some of the background material in the document, where I think
clarifications could help motivate the proposal.

1.  Proposal substance

Section 3.1 of the proposal includes this principle: "The proposed
replacement solution should not seek to create another ICANN-like
structure with associated costs and complexities."  This is a laudable
principle and I support it unreservedly.  Unfortunately, I think the
proposal as written, were it to be followed, all but guarantees the
creation of such a structure.

The proposal includes the Multistakeholder Review Team (MRT) and the
Customer Standing Committee (CSC).  The MRT is to be "a
multistakeholder body with formally selected representatives from all
of the relevant communities".  The MRT is to develop contract terms,
make decisions for another entity, perform budget and performance
reviews, manage a bidding process, and receive escalation from the
CSC.  The CSC is made up of registry operators.  These two structures
appear set respectively to replicate, only perhaps with different
personnel, the ICANN Board on the one hand and CCNSO and GNSO
(henceforth, the NSOs) on the other.  The probability that these two
new organizations would not turn out to reproduce the cost and
complexity of ICANN seems vanishingly small.  Indeed, given the MRT's
representative nature and responsibility for both budget review and
contracts, it is hard to see how MRT could keep out of the business of
making policy.  The potential for policy decisions in the MRT that do
not align perfectly with name-community policies expressed as ICANN
Board resolutions suggests that some sort of conflict resolution
mechanism would be needed, as well.  This will inevitably lead to
requirements for permanent staff, travel and legal services budgets,
and so on.

Worse, there is already only a small population of interested,
motivated, and available people for the work on the ICANN Board and
the NSOs.  The populations of the MRT and CSC are likely to draw from
the same pool.  If there were a formal requirement that the members
not overlap, then there would be substantial risk that much of the
membership would effectively just move back and forth, which offers a
potential for policy deadlock.  If there were not such a formal
requirement, then there would be a significant risk of at least the
appearance of self-dealing.  Anyway, since the MRT's relevant
communities are likely to be very similar to the ICANN Board's, and
since the CSC's relevant communities are by definition the same as
part of the NSOs', it is hard to see how the appearance of
self-dealing could ever be avoided completely.

In addition, the proposal appears to offer a mechanism that could foil
useful and necessary work.  While the inspiration for the Independent
Appeals Panel is noble, the proposal that "all decisions and actions
(including deliberate inaction) of the IANA Functions Operator that
affect the Root Zone or Root Zone WHOIS database be subject to an
independent and binding appeals panel" potentially makes every action
(or inaction) of IANA into an opportunity for litigation.  It is not
even plain, from the description, that the Independent Appeals Panel
would be prevented from overruling instructions that came from the MRT
or CSC; this creates an entirely new vector for attack on IANA
functions.  And because the Panel is not a standing body (this
function should more properly be called the Independent Appeals
Panels), it would be reconstituted for each dispute, which means that
there would be little institutional consistency.  Such a body would
reproduce the functional pattern of Uniform Dispute Resolution Panels,
which have been criticised in part for inconsistency from case to
case.  Other, similar appeal panels, such as the various ones around
string similarity and evaluation for TLDs, have similarly attracted
complaints about capricious ruling.  It is hard to see how the
Independent Appeals Panel would ensure a different result.

It appears to me that, at bottom, the proposal is attempting to
produce a mechanism that will check abuses and ill-considered outcomes
from the policy and contracting organization that we already have to
undertake that work: ICANN.  There is already an ICANN accountability
project underway (as the proposal notes).  It seems to me that it
would be much better for those improvements in accountability to be
delivered within ICANN structures, rather than to build another set of
organizations outside to try to check ICANN actions.

The proposal nevertheless includes an excellent idea.  The main thing
the NTIA actually does during any root zone or whois database change
is to ensure that the prevailing policy governing such a change is in
fact being implemented.  The proposed tiny, non-profit Contract Co
could be constituted to perform exactly this action.  It would have
the legal authority to deny any change.  Its sole responsibility would
be to ensure that the change met the prevailing policy, and then pass
that change along to the Root Zone Maintainer to be implemented.  If a
proposed change was not in keeping with the prevailing policy, then
the Contract Co would not pass the change along, and so the change
would not happen.  Otherwise, the Contract Co would pass the change
along.

Some will object that this minimal mechanism does not provide the
"credible threat" function of oversight that NTIA provides today.  But
presumably, the point of the accountability reform effort within
ICANN is that those reforms should provide oversight from the global
Internet community such that the threat is not needed.  Policy and
accountability mechanisms inside ICANN have to deliver what is needed.
If they cannot, then it does not seem likely that producing new bodies
external to ICANN, but made mostly of the very same people and with
similar responsibilities, is any more likely to produce the oversight
needed.

2.  Background materials

The inclusion of some of the background material is helpful, but some
of it might benefit from some changes.

In the discussion of "delegation" in section 1.2.4, it would be
helpful to note that "delegation" has acquired an ambiguous meaning.
In the DNS, delegation takes a quite specific technical form: it
involves placing NS records in a delegating (or parent) zone
corresponding to the authoritative name servers living at the apex of
the delegated (or child) zone.  Change the NS records in the parent,
and you thereby change the delegation.  In this narrow, technical
sense any change of a nameserver is a "redelegation", and there is not
even a requirement that delegation cross organizational boundaries.
For historical reasons, however, in the root zone the operator of a
child zone (that is, a TLD) was usually a different organization, and
simple changes of name server records have gradually come to be
treated differently than changes to the organization undertaking
operation.  Hence, the second meaning of "redelegation": changing the
organization operating a TLD.  It is critical that the two meanings be
made plain in the document, because people familiar with DNS
operations will treat statements about "delegation" differently than
those less familiar with DNS.  Perhaps the terms "technical
delegation" and "organizational delegation" could be used, though I
admit they're pretty awkward.

In section 1.2.7, there appears to be some conflation of different
kinds of key material.  There are potentially three different kinds of
key here, and it will not do to treat them as the same thing.  The
first is the Key Signing Key (KSK) for the root zone.  This is part of
the root zone's DNSKEY RRset, and the generation of that KSK is indeed
subject to a fairly elaborate ceremony.  This is because it represents
the anchor of all trust for the DNSSEC system, so complete
transparency in its generation and handling is critical.  A second
piece of key material is the hash of the KSK of each signed child
zone (in this case, the signed TLDs).  These need to be communicated
to the root zone operator from time to time, whenever a TLD operator
changes their KSK.  Such a change needs to be authenticated to ensure
the submission in question is coming from someone who has the rights
to make the update.  A third kind of keying material would be a public
key for a public-private key pair, used to ensure secured
communication between a registry operator and the IANA operator.  It
has been some time since I've administered a TLD, so I do not know
whether this is common practice now; but this is the sort of key
material that would "ensure that TLDs are able to communicate
securely" (at least, as I understand that phrase).

In section 2.1.2.1, there is a suggestion that RFC 1591 was written in
the "very early days" of the Internet.  It was certainly early days
for the commercialization of the Internet; but if we understand the
Internet to have begun in 1983 with the deployment of TCP/IP, then
1994 does not seem so early.  This sounds picky until one realizes
that what RFC 1591 was doing was codifying existing, fairly
well-established practice rather than setting new policy.  In
undertaking the current changes to the IANA arrangements, we could do
much worse than to follow the pragmatic approach undertaken by the
pioneers of the Internet, in preferring the continuation of existing
working procedures to any elaborate new ones.

I appreciate the opportunity to comment on the CWG proposal.  I hope
these comments are useful.

Respectfully submitted,

Andrew Sullivan

-- 
Andrew Sullivan
ajs@xxxxxxxxxxxxxxxxxx