[soac-newgtldapsup-wg] Re: Fwd: [council] Questions from RySG on JAS

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Proposed responses inline, with [RySG] anchored questions intact for
clarity.
---
> 3.2 Notes on Financial Need

On the proposed minimum applicant capability towards ICANN fees.

> */[RYSG] /* How was this determined? Is it sufficient to demonstrate
> viability? Some explanation of the WG thinking on this would be helpful.

ICANN used figures in this range in 2000 and 2004. As the final fee is not 
yet fixed, see fee reductions, elsewhere, this minimum applicant capability
is subject to increase, or decrease.


On the proposed minimum applicant capability towards operating costs.

> */[RYSG] /*Is the $45,000 amount an annual figure?  It might make up a
> very small percentage of operational costs.

Current offers of record by registry technical service providers to potential
applicants are significantly lower than this figure.

The total marketing budget PuntCat invested in .cat was 2,000 euros.


On the proposed minimum applicant capability towards continuity costs.

> */[RYSG] It would be helpful to explain the basis for the $45,000
> amount./*

Current offers of record by registry technical service providers to potential
applicants are significantly lower than this figure.

See offers made, by Eric Brunner-Williams and Jeff Neuman, on the tdg-legal
mailing list, on the de minimus individual, and shared costs for continuity,
respectively.

The figure is also subject to revision downward.

> *Part 4 - What benefits do qualified applicants receive?*
...
> [RYSG] If these contingency funds are actually needed at the amount
> estimated, where would the deficit come from?

Contingency is risk cost. As applications are reviewed to a higher standard
for eligibility, rational risk must, of necessity, be altered downward,
reducing rational contingency funding requirements.

The same question arises if the contingency funds actually needed are in
excess of the amount estimated, for applications not reviewed to a higher
standard for eligibility.

>     * Review Base cost (US$100,000) to see if reduction can be made
>     * Cost reductions to encourage the build out of IDNs in small or
>       underserved languages.
>
> */[RYSG] /*Does the WG believe that costs will be less for ‘IDNs in
> small or underserved languages’?  If not, what is being suggested here?

See Resolution 20 and references to diversity. The fees for underserved
communities are at the discretion of the Board.

>     * Lower registry Fixed Fees
>
> */[RYSG] /* Assuming the fees are reasonable with regard to services
> provided to registries, would other registries be expected to make up
> the deficit?  Or does the WG believe the fees are too high?  If the
> latter, was any analysis done to support that position?

The overwhelming bulk of registry fee income to ICANN comes from .COM.
With the exception of the .ORG redelegation, it is unclear that any 2000
or 2004 registry fixed fees provide a significant portion of ICANN's
general income sufficient to support "surplus" or "deficit" cliams.

The question fails to distinguish between the contract compliance cost
ICANN has experienced for registries lacking responsible sponsor policy
oversight, which are "willfully blind", e.g., .com, .biz, .jobs, and
registries where responsible sponsor policy oversight is exercised,
e.g., .cat, .org.

See also the response concerning contingency risk, as the same higher
review standard lower risk cost principle applies here.


>     * Exemption or deferment of IPv6 implementation requirements as
>       possible
>
> */[RYSG] /* Could this put the registry at a competitive disadvantage
> compared to registries that support IPv6?

In our opinion, no.

DNS providers who don't keep up with the market (which means IPv6 and dnssec
in this context) will lose business to those who do. However, this will not,
in our opinion, be relevant to new registries during the initial year(s) of
operation, while the IPv6 requirement is deferred.

> Further reductions recommended
>
>     * Reduction of the Financial Continued Operation Instrument
>       Obligation to 6-12 months
>
> */[RYSG] /* What if the registry fails?  Does the WG suggest a higher
> tolerance for failure in exchange for a smaller continued operation
> obligation?

The presumption of failure applies to all registries, including the 2000
and 2004 round applicants now, or their successors in interest, operating
registries.

The staff choice of three years of continuity funding rationally reflects
the failure scenario for applications made by speculators and other uninformed
investors. The eligibility criteria for applicants seeking support eliminates
these likely-to-fail applicants.

Eligibility criteria ensure that the likely elapsed time to continuity
operator discovery for registries "in continuity" arising from support
eligible applicants is significantly less than that of random speculator
driven failures.

See also the response concerning contingency risk, as the same higher
review standard lower risk cost principle applies here.

> 4.1.2 - Staggered Fees
>
> Instead of paying the entire fee upon acceptance of the applications,
> applicants meeting the criteria established for support could pay the
> fees incrementally. Staggered fees payment enables an applicant to
> compete for strings that might otherwise have gone to the first and/or
> only group with enough money to apply.
>
> */[RYSG] /* Staggered over what period of time?  What happens if
> progress payments are not made on time?

A review of the assistance offered to discover why the assistance has failed
to result in scheduled payment, and reasonable commercial efforts to ensure
errors in schedules, and errors in execution, have been redressed.

Current offers of record by registry technical service providers to potential
applicants provide guidance as to current commercially available terms for
payment schedules, and payment rescheduling.

> *Part 5 - Evaluation process and relationship to the new gTLD
> Applicant Guidebook (AG)*
...
> */[RYSG] /* Is there enough time for this?

ICANN's schedule, or process, is not under the control of the working group.
Therefore the question is not answerable.

---
Eric