Outline of IRTP-C Workplan

1.1 Reach out to other AC/SOs for initial comments

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

1.1.2.4 Encourage members to monitor the work/list

1.1.3.1 Any members of the group members of these groups?

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

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

1.2.1.1.1 Some issues were raised a long time ago -- are these questions still valid, given other measures that have been taken in the intervening time

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

1.2.2.1 There is no ICANN policy that addresses change of control

1.2.2.2 Currently missing from policy -- only transfer between registrar

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

1.2.2.4 Causes confusion/frustration -- registrars and registrants

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

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

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

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

1.2.3 Investigate how this function is currently achieved

1.2.3.1 Different interpretation/implementation/inconsistency between registrars

1.2.3.1.2 Develop strategies for smoothing out these differences?

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

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

1.2.3.4 Understand current definitions of "change of control"

1.2.3.4.1 Different rules for different circumstances

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

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

1.2.3.5.2 What specific features have specific effects

1.2.3.5.2.3 Lack of education in the process/policy

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

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

1.2.3.5.3.2 Current situation -- uneven knowledge of the process

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

1.2.3.5.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.2.3.5.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.2.3.6 Education Exercise -- Use real transfers between members of the working-group to demonstrate to us a real transfer

1.2.3.6.2.1 Everybody on their own, or a shared experience?

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

1.2.3.6.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.2.3.6.2.4 Use a an old/low-value name -- not a new one (which will hit the 60-day restriction)

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

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

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

1.2.3.6.2.5.1.1 1. simple change of registrar

1.2.3.6.2.5.1.2 2 change of control and registrar

1.2.3.6.2.5.1.3 3 change of control in same registrar

1.2.3.6.3.1.1.1.1.1 Simonnetta volunteers to be on the "gaining" side

1.2.3.6.3.1.1.1.1.2 Bob Mountain could be the losing registrar

1.2.3.6.3.1.1.3.1 Inter and intra-registrar transfers under way

1.2.3.6.3.1.1.5 Barbara as resource-person

1.2.3.6.3.1.1.5.1 Recent changes influence behaviors -- eg 60-day triggers

1.2.3.6.3.1.1.5.2 Beware of assisting too much -- skew results. :-)

1.2.3.6.3.1.2.1 Ensure all scenarios are covered

1.2.3.6.3.1.2.2 Format is similar enough for comparison

1.2.3.6.3.1.2.3 Submitted back by some date

1.2.3.6.3.2 Document personal experiences?

1.2.3.6.3.3 Do a transfer live in Adobe connect?

1.2.3.6.3.3.2 Messaging between registrars/registrants

1.2.3.6.3.3.3 Live screen share or screen shots (screen shots are easier to pull off)

1.2.3.6.3.4.1 Processes vary between providers

1.2.4 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.2.4.2 Reach out to members who have experience with ccNSO practices (Michele, etc.)

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

1.2.5.1 Identify where checks and balances and security are needed

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

1.2.5.3.2 "local law" approach is problematic

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

1.2.5.3.5 how to find out who you transact with online

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

1.2.5.4 Develop visual representations of "ideal" process (and existing ones for comparison?)

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

1.2.6.1 Include visual representation of the process(s) for review

1.2.6.2 Hold real-time workshop w/registrars in addition to requesting written comments

1.2.6.2.1.1 More flexible -- both timing and content

1.2.6.2.2 Before or after initial report?

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

1.2.9 Draft changes to existing (or new) policy

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

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

1.2.10 Draft educational materials/explanations

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

1.3.1.1.1 Some issues were raised a long time ago -- are these questions still valid, given other measures that have been taken in the intervening time

1.3.2.1.1 Need to identify existing use-cases

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

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

1.3.2.1.4 Unlimited expiration enables easy transfer of domains in the aftermarket

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

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

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

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

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

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

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

1.3.3.7 Look to public comments for initial information

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

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

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

1.3.5 Draft changes to existing (or new) policy

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

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

1.3.6 Draft educational materials/explanations

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

1.4.1 Get input from registries prior to starting

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

1.4.2.1.1 Some issues were raised a long time ago -- are these questions still valid, given other measures that have been taken in the intervening time

1.4.2.2 Identify justification, benefits and costs and how we demonstrate them

1.4.2.3 Identify impacts/harms to registrars in addition to registries

1.4.2.3.1 Are there material effects that result?

1.4.2.3.4 Identify streamlining/scaleability facets of the process

1.4.2.4 Explore security questions/issues

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

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

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

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

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

1.4.6 Draft changes to existing (or new) policy

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

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

1.4.7 Draft educational materials/explanations

1.5.4 Document how we dealt with the comments

1.5.6 Incorporate comments into subsequent drafts

2.2 Circulate constituency/stake-holder templates

2.2.1 General questions and detailed questions

2.2.2 Charter, issue report, WG are sources of questions

2.8 Publish final report and submit to Council