IRTP-C Workplan
+ - Reach out to other AC/SOs for initial comments
+ - Item A - change of control
+ - Understand why we're looking at this question -- what problems are we trying to solve
+ - Review Issue Report
Some issues were raised a long time ago -- are these questions still valid, given other measures that have been taken in the intervening time
Understand the connection between this question (Item A) and the FOA (Item B)
+ - There's a lack of guidance regarding COC
+ - One of the main issues is felt by the people who are trying to move domains -- and for them, this process is difficult, confusing, broken, etc.
+ - Background
+ - There is no ICANN policy that addresses change of control
There may be an implied change of control -- referenced in the UDRP (an option/outcome is change of controll)
ICANN has policy for a transfer of domains between accredited registrars -- but nothing like a change of control between registrants
+ - CC's have two concepts
There's an acknowledgement that the event occures, but little guidance as to HOW it occurs
+ - This is one of several areas where ICANN doesn't have policy -- and in some cases this is a problem that doesn't need to be fixed
But in the case of COC -- this gap creates a number of operational headaches that need to be addressed
+ - COC could also address another hole -- registrants are allowed to update their WHOIS data -- but the info in the "registrant" fields in WHOIS is the person.entity responsible -- registrars are also requied to have a contract with that person -- which leaves an opportunity for a bad actor to maliciously transfer a domain to a person with whom they don't have an acknowledged registration agreement. Unilateral blind pushing of the domain to a new registrant without the knowledge of the gaining registrar/registrant.
EG Registrar is held liable, even though contact details/relationship were all posted by a bad actor -- Michele can supply details of the example if needed
Currently missing from policy -- only transfer between registrar
Policy wasn't written with the after-market in mind
Causes confusion/frustration -- registrars and registrants
+ - Many combinations/scenarios -- escrow providers, registrars, etc.
+ - As a result, there are market-based solutions to provide this capability
Many of those use the IRTP as part of the mechanism
+ - IRTP wasn't intended to this purpose, but it's being used that to change control in addition to change registrar
+ - Investigate how this function is currently achieved
+ - Different interpretation/implementation/inconsistency between registrars
Understand the way transfers are being done in ccTLDs -- looking for the good and bad
Look at both ccTLDs *and* existing gTLD "change of account" type processes for models
+ - Understand current definitions of "change of control"
+ - Understand the connection between policy/practice and the experience of registrants
How the IRTP is normally done -- how can this be related to a particular registrant impact/effect/experience
+ - What specific features have specific effects
+ - Understand the shape of, and unintended consequences of, the arrival of the aftermarket
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
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
+ - Education Exercise -- Use real transfers between members of the working-group to demonstrate to us a real transfer
Everybody on their own, or a shared experience?
ICANN staff go through the process and "journal" their experience?
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.
+ - Use a an old/low-value name -- not a new one (which will hit the 60-day restriction)
+ - Maybe do one that's a change of ownership vs a change of registrar
+ - Covered pretty comprehensively with the sub-team slideshow, etc.
+ - Results from Matt's review with his team
+ - gTLD model -- registrar can send EPP commands to registry
middle ground -- either regirstrant deals directly with registry, or the registrar kicks the registry process EPP
the opposite -- physical process
+ - advantage to EU process -- trade and IRT can happen together
•.NL, ,MX, .DE, COCCA, Afilias and many others. The current registrar can send a domain update command to the registry and update any domain information (contacts or DNS).
•.GR process: the loosing registrant provides the auth code to the new domain holder. Transfer and ownership changes can be done at the same time.
•.EU and .FR. The registrar submits a "trade" EPP command. The registry then sends an email to the gaining and loosing domain owner with a link to approve the request. Once both parties approve the request, the registrar receives a poll message stating that the trade is complete. One benefit to this is a transfer and trade can be done together. For example, the gaining registrar can submit the trade command, once this is approved by both parties the ownership of the domain is updated and the domain is transferred to the new registrar.
•UK: The loosing registrant logs into their account with the registry and initiates the ownership change. The new registrant will then receive an email with a link to approve the request. This process is not done via registrars or EPP.
•.SE and .AU: Documents required through a random audit by the registry. The current registrar must have the loosing domain owner sign a document agreeing to the change of ownership. The registrar then submits a domain update command to the registry.
•.BR – the loosing registrant must sign documentation agreeing to the change. The original copies of the documentation must be submitted to the registry.
•.KR - The current and new domain registrants will be required to sign ownership change documents and provide a copy of their Korean Business Registration certificates or, if the current or new holders is an individual, a copy of their Korean personal identification (passport, driver’s license, etc).
•.EG, .JO, .OM - the loosing registrant and the new registrant must sign and notarize original documentation agreeing to the change. The original documents are then submitted to the registry to process.
If a TLD is using EPP than we do not need the option to processes orders in bulk. The downside to registries who process ownership changes in bulk, is the process generally changes all domains tied to a specific registrant handle and it becomes difficult to only modify specific domains.
+ - Results from Simonnetta
+ - Challenges
additional hurdles in process
confirmation of who is on the receiving end
+ - restrictions on who is allowed to own a TLD -- domain eligibility -- new registrant may need the same level of eligibility as the old
may be an important requirement in new community TLDs
needs to be acknowledged/handled/addressed in the transfer of control process
+ - roles may need to be defined for registrars/registries/registrants
There needs to be a way to express the difference between eligibility rules -- and the way of expressing those rules in the process -- between registry, registry service provider, registrar, registrant
build into "consent" process -- registrant is aware of and understand eligibility requirements
Refer this issue back to the GNSO Council as a heads up?
may want to send this issue back to the New gTLD team as a heads up
Two scenarious -- 1) you have to meet a requirements vs 2) ticking a box allows you to "join" the community very quickly
Likely to be complex and difficult to confirm eligibility -- we probably want to avoid geting too prescriptive
messy -- how would this confirmation take place? how do i know that this is an authorized transfer
may want to look at these more restrictive TLDs for models on how to build this into the process
difference between country-codes (sovereigns) vs gTLDs which lack that role -- indian tribes vs .XXX for example -- collides w/national law
+ - Just because a policy exists doesn't mean it's legal
non-electronic communication -- fax, mail, etc.
+ - Identify if there are any applicable models in the country-code space that can be used as a best practice for the gTLD space
Matt offers to poll team
Simonetta? Which cc's make transfers to dn's that make them easy, fast, secure?
Contractual structure? Tripartate is common in cc's, bilateral more common in gTLDs -- need to explore
+ - Thick vs thin -- .COM registry doesn't have the data to do COC events
+ - Draw up an "ideal" process based on what has been learned
+ - Send the "ideal process" back to the registrars for review and comment
Incorporate changes into "ideal"
+ - Determine whether such a policy is even appropriate for ICANN to consider
+ - Draft changes to existing (or new) policy
+ - Draft educational materials/explanations
+ - Action items
+ - Item B - time-limiting FOAs
Some issues were raised a long time ago -- are these questions still valid, given other measures that have been taken in the intervening time
Imposes extra maintenance-step on domain-aftermarket registrants who are looking to sell their names
Currently open to abuse --
+ - Security issues
Portability vs security
Are there mechanisms that are missing -- eg notification of gaining registrar of FOA expiration, or cancellation
Identify risks -- is there a way to mitigate risks without impacting the aftermarket
Look to public comments for initial information
+ - Get inputs from domainers -- people who actively trade domains
+ - Item C - Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDS
Get input from registries prior to starting
+ - Understand why we're looking at this question -- what problems are we trying to solve
Some issues were raised a long time ago -- are these questions still valid, given other measures that have been taken in the intervening time
Look to feedback from stakeholder groups and constituencies for initial information
Explore timing issues -- this may become a bigger issue when the number of registries goes up w/new gTLDs
Determine whether such a policy is even appropriate for ICANN to consider
+ - Draft changes to existing (or new) policy
Draft educational materials/explanations
+ - Public comment cycle(s)
+ - Publication and approval cycle