[soac-newgtldapsup-wg] On staggered fees versus reduced fees

[Evan Leibovitch <evan@xxxxxxxxx>]

Hi all,

I have long had a hard time with -- one could even suggest that I agonized
over --the notion that the JAS WG should advocate a "fallback" position of
recommending the staggering of gTLD fees, in case the Board were to reject
the primary recommendation of the WG (along with that of the GAC/ALAC
advice) for fee reduction.

My quandry: how do we properly convey that the two recommendations are not
equal, that they not be represented in a manner that allows for the Board to
spin that fee staggering -- *instead of* fee reduction -- is keeping with
the community direction. As far as I recall we also had good consensus that
staggered fees would be advisable in case staggered fees were rejected, and
it is prudent to ask for the staggering. All the same, it seems highly
illogical and counter-productive to me to include a recommendation whose
wording almost anticipates its being rejected.

Possible approaches:

   - Have the staggering proposal in a footnote, appendix, or secondary
   document
   - Create extremely strong wording to indicate staggering only as a "last
   resort" option
   - Leave out staggering entirely

But the one that I like best -- which also appears agreeable to Avri and the
original drafting group -- is none of these. My preferred approach is to
simply decouple the two proposals -- we recommend fee reductions AND we
recommend staggered fees, and we remove all text that suggests that
decisions made on one of the recommendations are based on another.

This impacts the wording for Section A.7 of the Draft document.

*Original wording (from Robert):*

For any Support-Approved Candidate who does not receive the fee reduction,
the fees should be staggered. Instead of paying the entire fee upon
acceptance of the application, a Candidate meeting the criteria established
for support could pay the fee incrementally. Staggered fee payment enables a
Candidate to compete for strings that might otherwise have gone to the first
and/or only group with enough money to apply.

*My original suggested change:
*

> Should ICANN fail to implement the fee reduction as stated in Section 4
> above – as explicitly recommended by this Working Group, the GAC and ALAC –
> Fees for any Support-Approved Candidate must be staggered. That is – instead
> of paying the entire fee upon acceptance of the application, a
> Support-Approved Candidate could have the option to pay the fee
> incrementally based on the stage of the application's processing. Staggered
> fee payment enables a Candidate to compete for strings that might otherwise
> have gone to the first and/or only group with enough money to apply.
>

*Andrew modified it further to this:*

Should ICANN fail to implement the fee reduction as stated in Section 4
above – as explicitly recommended by this Working Group, the GAC and ALAC –
the WG’s strong recommendation is that fees for any Support-Approved
Candidate must be staggered. That is – instead of paying the entire fee upon
acceptance of the application, a Support-Approved Candidate could have the
option to pay the fee incrementally based on the stage of the application's
processing. Staggered fee payment enables a Candidate to compete for strings
that might otherwise have gone to the first and/or only group with enough
money to apply.

*I am NOW recommending the wording be changed to this:*
*
*
>
> *The WG recommends that gTLD fees for Support-Approved Candidates should
> be staggered. Instead of paying the entire fee upon acceptance of the
> application, a Candidate meeting the criteria established for support could
> pay the fee incrementally. Staggered fee payment enables a Candidate to
> compete for strings that might otherwise have gone to the first and/or only
> group with enough money to apply.*
>


This makes the issue of staggering fees (a matter of payment timing)
distinct from the issue of reduction (a matter of the amount to be paid).
Furthermore, it eliminates the tactical quandries related to linkage.

Is this acceptable?




Evan Leibovitch, Toronto Canada
Em: evan at telly dot org
Sk: evanleibovitch
Tw: el56