ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Comments on the CWG-Stewardship's 2nd Draft Proposal

  • To: comments-cwg-stewardship-draft-proposal-22apr15@xxxxxxxxx
  • Subject: Comments on the CWG-Stewardship's 2nd Draft Proposal
  • From: Dr Eberhard W Lisse <el@xxxxxxxx>
  • Date: Wed, 20 May 2015 20:28:39 +0100

(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

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


  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


  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

  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?


  What does a ccTLD Manager actually need from the IANA Function


        Root Zone Change Request Management - not including
        delegation and redelegation (NTIA IANA Functions Contract:


        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

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

Dr Eberhard W Lisse
Managing Director
Namibian Network Information Centre (Pty) Ltd.
PO Box 8421 Bachbrecht

Attachment: cwg-comment1.pdf
Description: Adobe PDF document

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy