Comments on the CWG-Stewardship's 2nd Draft Proposal
(also attached as PDF)
Dear Colleagues
I am the Managing Director of Namibian Network Information Center
(Pty) Ltd, the country code Top Level Domain Manager of .NA and have
been appointed as member of the CCWG-Accountability by the ccNSO.
I wish to make the following comments on the 2nd Draft Proposal of
the Cross Community Working Group to Develop an IANA Stewardship
Transition Proposal on Naming Related Functions (CWG-Stewardship):
1. The CWG-Stewardship Proposal is convoluted and as it is
presented in a pre-set format it is difficult to read, especially
for non native English speakers.
2. The CWG-Stewardship worked
[...] on the premise that there is current satisfaction
with ICANN's IANA department performance and that ICANN
should remain the IANA Functions Operator.
Neither of the two assumptions is correct in my opinion. The
former is apparently based on a survey about response time to
uncontroversial requests, such as Name Server or Whois Data
changes.
3. The proposal does not address IANA administrative and
operative accountability sufficiently, which in terms of the
CCWG-Accountability Charter (!) it is supposed to do.
This is apparent from "Annex H - Service Level Expectations" which
refers to Service Level Expectations "currently under discussion"
listed on https://community.icann.org/x/CA4nAw which speak for
themselves. In particular the unsigned
https://www.icann.org/en/system/files/files/didp-response-20150407-1-kane-07may15-en.pdf
where ICANN flat out rejects the request for
the disclosure of all work-flow process documents with
accompanying performance statistics for each stage of the IANA
Root Zone Management function.
This is even better characterized by an email of the SLE Design
Team leader Paul Kane to the ccNSO Council Chair Byron Holland on
the ISTACC Mailing list 2015-05-08:
[...]
The really frustrating thing we just want a professional and
fit for purpose SLE (that is standard practice in today's
environment) and are being "fobbed off" with "national
security" issues - and if ICANN requires a classified
meeting a number of the Design Team members are cleared for
Classified national security discussions to the category
"Top Secret".
Please note: we are not proposing the IANA SLE requires the
same performance standards that ICANN expects from gTLD
Registries but rather an SLE that captures the current
detailed workflow and the actual performance delivered by
IANA.
[...]
I personally do not agree with Paul Kane's offer of limiting
access to the requested material to individuals possessing a
high security clearance from the US Government. Instead the CWG
Stewardship should have stopped their work at that stage, gone
public, and continued only if and when the required information
had been provided.
4. Throughout the document reference is had to "customer" "of the
service or activity".
The word customer implies a measure of voluntary choice, and a
bilateral agreement between the customer and the provider of the
service. In the case of a ccTLD the former would be the ccTLD
Manager and the latter the IANA Function Manager (currently
ICANN).
None of these exist, with very few exceptions of a handful of
ccTLD Managers having entered into agreements.
5. What does a ccTLD Manager actually need from ICANN?
Nothing!
What does a ccTLD Manager actually need from the IANA Function
Manager?
Only
Root Zone Change Request Management - not including
delegation and redelegation (NTIA IANA Functions Contract:
C.2.9.2.a)
and
Root Zone "WHOIS" Change Request and Database Management
(NTIA IANA Functions Contract: C.2.9.2.b)
The rest of the services listed there are not required, per se,
including DNSSEC. Delegation service is a one time occurrence,
which does not affect the ccTLD Manager once completed.
Besides the use of outdated terminology ("redelegation" has been
replaced by the term "revocation") it must also be said that
hardly any ccTLD Manager wishes to avail oneself of un-consented
revocation services by the IANA Function Manager.
6. On the other hand what does ICANN actually need?
The root zone and/or the IANA Function.
7. That brings me to other issue that has been carefully avoided,
the actual root zone.
Without a shadow of a doubt the root zone is a database and
clearly is an asset, ie some form of property, even though it
is very closely linked to the services such as Root Zone Change
Request Management and Root Zone "WHOIS" Change Request and
Database Management.
And the issue is not what type of property it is, but what will
happen to it. In other words, who owns the root zone, and will
ownership be transferred?
From this the question follows, what will happen if only the
functions to manage but not the ownership of the root zone itself
is transferred?
8. This then raises the unanswered question under what statutory
powers this transfer will occur. And this question must be
answered in order for any transfer of the functions and/or the
root zone to occur.
9. The elevation of the GAC Principles and even the throughly
discredited ICP-1 not only negates several years of work of the
Framework of Interpretation Working Group but are plainly not
acceptable.
10. To create a entity separate from, but controlled by ICANN is in
my view unacceptable as it just creates additional layers of
bureaucracy without changing anything.
With Kind Regards
el
--
Dr Eberhard W Lisse
Managing Director
Namibian Network Information Centre (Pty) Ltd.
PO Box 8421 Bachbrecht
Namibia
Attachment:
cwg-comment1.pdf Attachment:
smime.p7s |