[SubPro-IRT] Work Plan is way too conservative and we need to do better......

Tue May 23 15:14:26 UTC 2023

Dear SubPro Team,

Background
I have been doing a bunch of thinking on the proposed work plan and I 
really believe we need to push much harder on the timelines being 
proposed and that we need to be much more aggressive.

For those of you that do not know me, I was one of the co-chairs of the 
SubPro Working Group with Cheryl, so we have been living and breathing 
all of this for years.  But in addition to that, I have participated in 
every one of ICANN's new gTLD rounds (starting in 2000), and have 
implemented not only hundreds of policies for registries, but I have 
also personally been involved in the launch of hundreds of TLD 
registries.  From 2011-Jan 2015, I was responsible for the Neustar 
Registry business that included supporting hundreds of new gTLD 
applications both as front and back-ends, but also included the launch 
of most of those TLDs.

Specific Comments to Workplan
According to the Workplan, it says that Modules 1-3 (as ICANN has 
designated will take about a year.  Then Modules 4-8 are listed as each 
one taking 3-4 months and operating serially one after the other.  And 
Modules 9 and 10 are not even included in the scheduling (which I am 
hoping means they will be overlapping).

It should be noted, however, that as far as I can tell, Module 1 
overlaps with practically every other Module and once we get done with 
Module 1, that constitutes the bulk of the work.  For example, the 
following topics seem to be in Module 1:
Predictability - which would include the SPIRT
Applicant Freedom of Expression
Different TLD Types
Conflict of Interest
Applications Assessed in Rounds (Overlaps with Module 2)
Metrics / Monitoring
Dispute Resolution Procedures - Question Why is this not covered in 
Module 4?
Reserved Names - If this refers to the top-level, fine; but second level 
is more Module 6
GAC Consensus Advices / Early Warnings
IDNs
Auctions / Resolution of Contention Sets
Registry/Registrar Standardization / Registrar Non-Discrimination 
(Should be in Module 6)
Comments on Modules 1-5 will come separately.

But I wanted to comment on Modules 6-8 and the Workplan.  There is no 
reason why Modules 6, 7 and 8 (contracting, Post-Contracting, and Terms 
and Conditions should take 3-4 months each (for 9-12 months total).  
Realistically, there is no reason these 3 modules should take any longer 
than 2 months combined.  That alone would shave off 7-10 months off the 
plan).

This is because:

a) Module 6 - Contracting:  Topics 36-38 of Final Report - I honestly 
believe this can be done in a couple of weeks
     1.    Topic 36- The final report contains 2 Affirmations and 2 
Recommendations, namely:
  Affirmation of the 2007 policy which is already included in the 2013 
Base Registry Agreement as amended....so this affirmation does not 
require any work.
Affirmation of the use of "Specifications" - No additional work required
Recommendation that ICANN add a contractual provision stating that 
Registry Operator will not engage in fraudulent or deceptive practices. 
- No IRT work needed
Recommendation that there should be some opportunity to negotiate 
contracts / exemptions subject to notice and comment in cases where 
there are unique aspects of strings or operators and provides ability to 
accommodate changing marketplace.  This one will require a little work, 
but overlaps with TLD Types in Module 1
     2.    Topic 37:  Registrar Non-Discriminating / Registry/Registrar 
Standardization.  This is already in Module 1, but really should only be 
here.

1 recommendation:  which states that Registries must use only ICANN 
accredited Registrars in registering domain names, and may not 
discriminate among such accredited registrars unless an exemption to the 
Registry Code of Conduct is granted as stated therein,provided, however, 
that no such exemptions shall be granted without public comment.”

This has already been implemented except for one thing.....Only thing 
added here is that if a Registry seeks an exemption to the Code of 
Conduct, there should be a comment period before granting the request.

3.    Topic 38:  Registrar Support for new TLDs  - This one is just an 
affirmation which requires no new implementation at all.  It just states 
that registrars can determine which TLDs it wants to offer.

Module 7 :  Post Contracting - I believe this can be done in 2 weeks at 
most
I assume this relates to Topics 39-41 of the Subpro Final Report
     a)  Registry System Testing 6 Recommendations here which essentially 
state that the ICANN should develop testing to demonstrate the technical 
capabilities of the registry which includes testing readiness for 
DNSSEC.  It states that testing must be efficient and need not be done 
multiple times for the same operator it that operator supports multiple 
TLDs.  Then it calls for the implementation of 2 recommendations that 
were already contained within the ICANN staff's own Program 
Implementation Review Report in 2016 or so.

     b)    TLD Rollout:  This contains 2 affirmations of what was done in 
2012.  No new implementation work needed.

c)    Contractual Compliance - consists of an affirmation of the 
sanctions policy (already in place) and a recommendation for ICANN 
Compliance to publish more stats on rationale for closing cases (Mostly 
implemented already).

Module 8:  Terms and Condition - Only real work is (d) below.  My time 
estimate:  3 weeks at most.

4 Recommendations; 3 Implementation Guidance

a)  ICANN should only reject applications if done so in accordance with 
Guidebook, Bylaws, laws, etc.  This recommendation is being discussed 
with GNSO/Board, but if accepted this requires a very limited couple of 
words being changed.

b)  ICANN should publish specific reason by applications are rejected 
but should avoid disclosing confidential information.  - Requires no new 
implementation in advance.

c)  Ts and Cs should only have covenant not to sue if there is an 
appeals/challenge process.  This is still being discussed, but at end of 
day, if there is no appeals, then implementation is crossing out 
covenant not to sue.  If there is one, implementation is keeping things 
the way they are. No new work likely.

d)  Refunds - This one will require some implementation work to define 
circumstances where refunds will be given due to changes made in the 
program where such changes materially impact applicants. -  Note this is 
being discussed with Board, but assuming Board approves, then work here 
is just coming up with a definition of "material impact" and ensuring 
that is not gamed.

e) Name Collisions - if ICANN cannot delegate a TLD because of name 
collision reasons, then a full refund should be given.  No real new 
implementation work.

f)  Confidential portions of applications should only be disclosed to 
those with a need to know...my paraphrasing.  But no new implementation 
work here really because this is standard in all Non-disclosure 
agreements.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/subpro-irt/attachments/20230523/c6c142e9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: njmdxlah.png
Type: image/png
Size: 11989 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/subpro-irt/attachments/20230523/c6c142e9/njmdxlah-0001.png>