Outline of IRTP-C Workplan

1.1.1 Required to follow the old process until the new process is approved by the Board -- probably in January

1.1.2 Approach -- follow the new process unless directly contradicted by the old

1.1.3 Question -- Charter questions -- one by one, or in parallel?

1.2.3 "Pencil in" intermediate deliverables/dates

1.3 Put review-sessions at the beginning of each "block" of meetings -- use that to refine schedule with (and get buy-in from) WG -- revisit workplan, lay out next series of deliverables

1.4.1.4.1 maybe a different approach -- we're looking for more from them

1.4.2.4 Encourage members to monitor the work/list

1.4.3.1 Any members of the group members of these groups?

1.4.3.2 They could be the lead people bring this up within their

1.5.1.1.1 Understand why we're looking at this question -- what problems are we trying to solve

1.5.1.1.1.1 Understand the connection between this question (Item A) and the FOA (Item B)

1.5.1.1.2.1 There is no ICANN policy that addresses change of control

1.5.1.1.2.2 Currently missing from policy -- only transfer between registrar

1.5.1.1.2.3 Policy wasn't written with the after-market in mind

1.5.1.1.2.4 Causes confusion/frustration -- registrars and registrants

1.5.1.1.2.5 Many combinations/scenarios -- escrow providers, registrars, etc.

1.5.1.1.2.6 As a result, there are ad hoc market based solutions to provide this capability

1.5.1.1.2.7 Many of those use the IRTP as part of the mechanism

1.5.1.1.2.8 IRTP wasn't intended to this purpose, but it's being used that to change control in addition to change registrar

1.5.1.1.3 Determine whether such a policy is even appropriate for ICANN to consider

1.5.1.1.4 Investigate how this function is currently achieved

1.5.1.1.4.1 Different interpretation/implementation/inconsistency between registrars

1.5.1.1.4.2 Understand the way transfers are being done in ccTLDs -- looking for the good and bad

1.5.1.1.4.3 Look at both ccTLDs *and* existing gTLD "change of account" type processes for models

1.5.1.1.4.4 Understand the connection between policy/practice and the experience of registrants

1.5.1.1.4.4.1 How the IRTP is normally done -- how can this be related to a particular registrant impact/effect/experience

1.5.1.1.4.4.2 What specific features have specific effects

1.5.1.1.4.4.2.3 Lack of education in the process/policy

1.5.1.1.4.4.3 Understand the shape of, and unintended consequences of, the arrival of the aftermarket

1.5.1.1.4.4.3.1 Needs to be brought into "mainstream" of ICANN policy-making process

1.5.1.1.4.4.3.2 Current situation -- uneven knowledge of the process

1.5.1.1.4.4.3.2.3 Question: what proportion of transfer issues are aftermarket related -- question to ICANN Compliance

1.5.1.1.4.4.4 Note -- there are other change of control mechanisms than just the aftermarket -- corporate agreements, mergers, tax issues, legal issues, death in the family for example

1.5.1.1.4.4.5 Rob Golding (othello): a change of registrar doesnt mean a changeof control - you either have to change it at the existing regsitrar first, or after the transfer - in both cases it has to be auditted

1.5.1.1.4.5 Education Exercise -- Use real transfers between members of the working-group to demonstrate to us a real transfer

1.5.1.1.4.5.2.1 Everybody on their own, or a shared experience?

1.5.1.1.4.5.2.2 ICANN staff go through the process and "journal" their experience?

1.5.1.1.4.5.2.3 Avri Doria: good idea to have a time lapse interaction. The transfer often takes longer than the course of one meeting, though it can be done quite quickly on occasion.

1.5.1.1.4.5.2.4 Use a an old/low-value name -- not a new one (which will hit the 60-day restriction)

1.5.1.1.4.5.2.4.1 Avri Doria: i am a impulse buyer, i have lots of names we could use for the experiment.

1.5.1.1.4.5.2.4.1.1 e.g. protect-the-commons.info

1.5.1.1.4.5.2.5 Maybe do one that's a change of ownership vs a change of registrar

1.5.1.1.4.5.2.5.1.1 1. simple change of registrar

1.5.1.1.4.5.2.5.1.2 2 change of control and registrar

1.5.1.1.4.5.2.5.1.3 3 change of control in same registrar

1.5.1.1.5 Identify if there are any applicable models in the country-code space that can be used as a best practice for the gTLD space

1.5.1.1.6 Draw up an "ideal" process based on what has been learned

1.5.1.1.6.1 Identify where checks and balances and security are needed

1.5.1.1.6.3 Ensure that it does a good job of identifying the proper parties to the transaction

1.5.1.1.6.3.1 Who's getting, who's taking?

1.5.1.1.6.3.2 "local law" approach is problematic

1.5.1.1.6.3.4.1 Relationship with local law -- different national laws -- intersection w/policy

1.5.1.1.6.3.5 how to find out who you transact with online

1.5.1.1.6.3.6 Look at admin-contact/registered-name-holder duality -- may not work here

1.5.1.1.7 Send the "ideal process" back to the registrars for review and comment

1.5.1.1.8 Incorporate changes into "ideal"

1.5.1.1.9 Draft changes to existing (or new) policy

1.5.1.1.9.1.1 Something that is simple, easy to use, clear, understandable

1.5.1.1.9.1.2 Improve the user experience -- especially for first-time users

1.5.1.1.10 Draft educational materials/explanations

1.5.2.1.1 Understand why we're looking at this question -- what problems are we trying to solve

1.5.2.1.2 Identify use-cases and scenarios

1.5.2.1.2.1.1 Need to identify existing use-cases

1.5.2.1.2.1.2 Understand what is currently being done and why -- what are the advantages and disadvantages

1.5.2.1.2.1.3 Explore impact of FOA -- pointing at specific registrar (or syndicate)

1.5.2.1.2.1.4 Unlimited expiration enables easy transfer of domains in the aftermarket

1.5.2.1.2.2.1 Does the current FOA have any time constraints at all?

1.5.2.1.2.2.2 We don't think there's anything in policy today -- need to verify

1.5.2.1.2.2.3 Possible Goal -- balance the needs of all users/registrants

1.5.2.1.3.1 Imposes extra maintenance-step on domain-aftermarket registrants who are looking to sell their names

1.5.2.1.3.3.1 Have people lost domains due to an FOA being out there but forgotten about

1.5.2.1.3.5 Are there mechanisms that are missing -- eg notification of gaining registrar of FOA expiration, or cancellation

1.5.2.1.3.6 Identify risks -- is there a way to mitigate risks without impacting the aftermarket

1.5.2.1.3.7 Look to public comments for initial information

1.5.2.1.3.8 Get inputs from domainers -- people who actively trade domains

1.5.2.1.3.8.1 Bob and Simonetta to reach out to large domainers for public comment?

1.5.3 Item C - Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDS

1.5.3.1.1 Get input from registries prior to starting

1.5.3.1.2 Identify justification, benefits and costs

1.5.3.1.2.1 Identify impacts on registrars in addition to registries

1.5.3.1.2.2 Explore security questions/issues

1.5.3.1.2.3 Look for reasons why not to do this -- include in the instructions for stakeholder feedback

1.5.3.1.2.4 Why aren't they being used, level of effort required to change.

1.5.3.1.3 Look to feedback from stakeholder groups and constituencies for initial information

1.5.3.1.4 Explore timing issues -- this may become a bigger issue when the number of registries goes up w/new gTLDs

2.2.2 Training session -- outside the working-group process

2.2.3 Go to the list to see if there's interest

2.2.4 Use Registrar-training video? new powerpoint?

2.2.5 Volunteer needed to run the training - James will run the session

3.2 Circulate constituency/stake-holder templates

3.2.1 General questions and detailed questions

3.2.2 Charter, issue report, WG are sources of questions

3.8 Publish final report and submit to Council