ICANN ICANN Email List Archives

[3gtld-transition]


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

Performance Specifications

  • To: 3gtld-transition@xxxxxxxxx
  • Subject: Performance Specifications
  • From: Elmar Knipp <elmar.knipp@xxxxxxxxxxx>
  • Date: Sun, 22 Nov 2009 22:34:02 +0100 (MEZ)

Here are COREs comments to the DAG v3 regarding the "Performance Specifications" in the "New gTLD Agreement":


(1) It was COREs understanding of previous statements from ICANN that the
    Performance Specifications are tailored to the needs of the applicant.
    A small cultural linguistic TLD has different demands compared to
    a high secure TLD for the financial sector.

    DAG v3 has chosen a uniform approach. This increases
    unnecessarily the entry barriers of smaller applicants.

    Contrary to that, CORE would like to see three categories.
    CORE is willing to contribute concrete specifications to ICANN
    on request.


(2) We fully understand the need for a stable and robust infrastructure.
    Therefore we encourage the choosen metrics for the DNS itself.

    But it is doubtful, whether the same values should apply to the SRS
    (EPP). In our view, it does not harm registrants, if the SRS is down
    for maintainance for longer than 43 minutes per month
    and registrars could not interact with the SRS in this downtime.

    It is also questionable, why the new values are higher compared to
    current registry operators contracts (e.g. COM/NET from VeriSign).


(3) The draft is unspecific who determines the probes and testpoints:
    (a) DNS: Who many probes are needed?
    (b) What does "... shall be placed as near as possible to the DNS
        resolvers on the networks with the most users accross the
        different geographic regions ..." mean? This is highly unspecific.
        An objective metric has to be given.
    (c) If ICANN wants to change the places of the probes, ICANN should
        pay for the change.

    Please provide more specific language and a rationale for the changes
    to v2 and how registrants benefit from the choosen approach.


(4) DNS update times are set to a maximum of 15 minutes. There are
    scenarios, where longer update times are wanted (e.g. to prevent
    name drop catching).

    It should be in the Registries discreation which model is chosen.


We hope these comments are helpful.

Best regards,
Elmar Knipp

--
Elmar Knipp (on behalf of CORE)
CORE Internet Council of Registrars   http://corenic.org
WTC II, 29 route de Pre-Bois, CH-1215 Geneva, Switzerland


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

Privacy Policy | Terms of Service | Cookies Policy