[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 29 July 2019

Tue Jul 30 00:43:10 UTC 2019

I'm, well, intrigued by this construct  'wilful gaming'? Like, when do you
know it? In process or at rest?

For gaming, howsoever defined, I'm figuring it's the results that matter,
yes?

So, could the same result be achieved by "unwilful" gaming?  Or, saying it
another way, purely by happenstance and absent forethought?

These questions came top of mind because it appears these ideas on the ASP
seem regenerative.

I watched them played out in the 2012 program as Co-Chair of the ASP WG.

What was clear then and from early in the game was that the obstacle course
of a process defined for applicants to receive support would have had a
chilling effect.

I truly believed that virtues aside, they discouraged prospects.

Under then extant rules I could not publicly denounce them then. I can
denounce them now.

Carlton

On Mon, 29 Jul 2019, 4:42 pm Julie Hedlund, <julie.hedlund at icann.org> wrote:

> Dear Working Group members,
>
>
>
> Please see below the notes from the meeting today, 29 July 2019. *These
> high-level notes are designed to help WG members navigate through the
> content of the call and are not a substitute for the recording, transcript,
> or the chat,* which will be posted at:
> https://community.icann.org/display/NGSPP/2019-07-29+New+gTLD+Subsequent+Procedures+PDP.
>
>
>
>
> Kind regards,
>
> Julie
>
> Julie Hedlund, Policy Director
>
>
>
> *Notes and Action Items:*
>
>
>
> *Action Items:*
>
> *From 15 July 2019*:
>
> ACTION ITEM 1: Applicant Freedom of Expression - Input on Implementation
> Guidelines - LRO:  Work on language for the high-level agreement to reflect
> fairness and balance.
>
> ACTION ITEM 2: Universal Acceptance: Rewrite the high-level agreement
> text.  Include a link to the USAG work.
>
>
>
> *From 18 July 2019*:
>
> ACTION ITEM 3: On this comment: Concerns: ICANN org - ICANN org is not
> aware of any “75 steps” document and is unclear about what “documentation
> related to the process used in setting fee in the 2012 round is being
> referenced in this section. It would be helpful if the PDP Working Group
> could clarify.  ACTION: To the WG to clarify.
>
>
>
> *From 25 July 2019*:
>
> Application Submission Period:
>
> ACTION ITEM 1: New Ideas: BC Comment -- Clarify what they mean by
> “Consider providing “a way to keep non-contentious applications open if
> they need more time to complete.””
>
>
>
> ACTION ITEM 2: Application Submission Period, possible new High-Level
> Agreement -- An application submission period or communication period
> should not be considered separately, but taken together. There should be a
> formal communication period of at least 6 months, but there is nothing to
> prevent efforts to provide awareness outside of that period.
>
>
>
> ACTION ITEM 3: New High-Level Agreements:
>
> -- All subsequent windows should be the same length as the initial
> application window.
>
> -- The communications period should commence at least 6 months prior to
> opening the application submission period.
>
>
>
>  ACTION ITEM 4: If someone applies for a string that is unresolved from a
> prior round would there be a refund?  Refunds haven’t been discussed, but
> need to be at a meeting and on the list.
>
>
>
> Applicant Support:
>
> ACTION ITEM AND NOTE: Consider adding to high-level agreement: Applicants
> that don’t meet the requirements should have the option to withdraw their
> application or pay the remaining application fee.  NOTE: Need to consider
> the timing of the application being accepted, particularly if the applicant
> is receiving other types of assistance.  Also, need to consider concerns
> about gaming (see ICANN Org’s comment).
>
>
>
> *From 29 July 2019*:
>
> *For Discussion: There seems to be support for an applicant support
> program that fails to meet the criteria for applicant support, that they
> are able to switch their string to a mainstream application process.
> Variations on implementation and concerns that need to be discussed.*
>
> *For Discussion: There Seems to be support that there should not be
> prioritization just because you are an applicant support application.*
>
>
>
> *Notes:*
>
>
>
> 1. Updates to Statements of Interest: No updates provided.
>
>
>
> 2. Review of summary document: (continued) – See:
> https://docs.google.com/document/d/11mtncTwPLPx6vpbunACToRZy1vWyls-MxVAb3wqEYsk/edit?usp=sharing
>
>
>
> Application Submission Period, page 18
>
>
>
> *Policy goals:*
>
>    - New Idea: ICANN Org - To ensure that the program is designed,
>    implemented, and operated to meet its intended purpose, PDP should define
>    the goals and key success factors for the program.
>
>
>
> Ability to transfer to standard application if application does not meet
> ASP criteria (see also related topic: Prevention of “gaming the system”):
>
>    - New Idea: ALAC/RySG - If transfer is permitted, applicant must be
>    given a reasonable amount of time to pay the additional fee.
>
>
>
> *Prevention of “gaming the system”: *
>
>    - Concern/New Idea: ICANN Org - 2012 rules preventing transfer from an
>    ASP to standard application were put in place after extensive community
>    discussion in order to prevent gaming. If there are no penalties or other
>    mechanisms to prevent gaming and no geographic location criteria, there
>    will likely be many ASP applications. The WG should consider the impact on
>    costs to process applications and to fund applicants who do qualify, as
>    well as the impact on program timelines.
>
>
>
> Discussion:
>
> -- Opportunity for an applicant to move from the Applicant Support program
> to the regular program, but to allow reasonable time.
>
> -- So, ICANN's Org point over gaming is noted but the potential incidence
> of gaming should be handled differently and not be the main cause of
> dampening the number of potential applicants for ASP.
>
> -- Correct, ICANN org’s comment is not an objection against allowing
> applicants to pay the remaining fees to continue in the program, but rather
> was meant to raise a potential issue for the PDP WG to discuss.
>
> -- Need to think about what we mean by “reasonable amount of time”.  Might
> depend on whether the string is in contention, so whether you are holding
> up other applicants.
>
> -- Question: Does the WG believe the potential for gaming is to be
> accepted, or should alternative mitigations be explored?
>
> -- Question: If the applicant can transfer into the mainstream process,
> does the string stay the same?  Answer: Would think that with any transfer
> the string must stay the same.
>
> -- There is also gaming that would happen if an applicant is denied
> support and then moves into the mainstream then you could come into
> competition.
>
> --  Another form of gaming in moving to the mainstream application process
> if there is an ability to change the string.
>
> -- In terms of mitigations, for instance, there could some form of a quick
> look mechanism, akin to that in objections.
>
> -- There are a couple of dependencies, such as with approval of a
> geographic name.
>
> -- Reiterate that the timing of the evaluation of applicant support  vs
> timing of the application process is important here.
>
> -- Discussion in the work track about a possible penalty for switching
> programs.
>
> -- the tangible benefit from 2012 version of Applicant Support was limited
> to a reduced fee amount. It had no bearing on the type of application or
> string type.
>
> *-- For Discussion: Seems to be support for an applicant support program
> that fails to meet the criteria for applicant support, that they are able
> to switch their string to a mainstream application process.  Variations on
> implementation and concerns that need to be discussed.*
>
>
>
> -- Applicants claiming support would be notified BEFORE the "big reveal"
> that they don't qualify for support - and would have to commit to pay the
> full amount - and the applicants for THAT string (if there are several)
> will only be revealed after ALL applicants have paid their full fees. Then
> the "gamer" has no information "gain" - and gaming makes no sense anymore.
>
>
>
> Additional Text from the ALAC:
>
>    - Applicants (including their representatives) whose application(s)
>    are determined by SARP to be subject of willful gaming should be disallowed
>    from participating in any application for Applicant Support for a specified
>    period. SARP’s evaluation methodology should include a component for
>    determining incidences of willful gaming.
>
>
>
> -- Some of this depends on the support being provided through the program,
> but I agree with the principle that willful gaming should be discouraged.
>
>
>
> *Eligibility:*
>
> -- Applicant support doesn’t mean applicant priority.
>
> -- If we hang this on “underserved region” we need to think what that
> would mean.
>
> -- Need to define what is “underserved” and “middle applicant”.  Are these
> defined by the UN?
>
> -- I can't remember exactly what was said but there was discussion on the
> regions that the UN designated as underserved and how applicable/up to do
> the list is/what it is updated.
>
> -- ICANN Org is starting to look at what “underserved” and
> “under-represented” might mean.  Moving away from the term “Global South”.
> There are various definitions out their including in the UN about
> “underserved”.  They tend to be very specific to medical or health issues.
> Doesn’t seem to be a single definition. It might be helpful to have a
> consistent usage across the Org and the community.
>
> -- Consistent between ICANN Org and community definitions -- also from an
> evaluation perspective, for a more objective evaluation then it will be
> helpful to have a very narrow definition.  ICANN Org used UN lists for
> 2012.
>
> -- ICANN Org is not trying to dictate the outcomes of the PDP discussions.
>
> -- Could we please have an action item to ask ICANN Org to share their
> thinking on "underserved/under-developed communities/regions" 'in moving
> away from Global South'?
>
>
>
> *For Discussion: There should not be prioritization just because you are
> an applicant support application.*
>
>
> _______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190729/6690ac45/attachment-0001.html>