| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Trigger from the Transfer Policy: II.A.1.1.1 Prior Registrant name + II.A.1.3.1 A change to the Registered Name Holder's name or organization that does not appear to be merely a typographical correction; | |||||||||||||||||||||||||
2 | Remains w/ Registrar & No Change of Control | In Close Proximity to or as Part of Change of Control | Followed by Inter-Registrar Transfer | |||||||||||||||||||||||
3 | Name | Action by RNH or Designated Agent Legitimate? | Possible to Distinguish between Legitimate or Illegitimate? | Possible to Distinguish if the Update is a Typographical Correction? | Are current policy requirements fit for purpose? | Proposed Action, if any | Are current policy requirements fit for purpose? | Proposed Action, if any | Are current policy requirements fit for purpose? | Proposed Action, if any | Components of possible recommendation(s) and rationale and additional comments, if applicable | |||||||||||||||
4 | Tucows (Sarah Wyld & Rich Brown) | Yes | No | Not easily e.g. Goerge > George could be typographical, but is George > Jorge typographical or not? Unclear. | Changing the Registrant name is not necessarily a change in control of the domain, although it could be a change of ownership. The purpose at hand is preventing theft of the domain name; in this scenario, the problem is not the name change, rather, it is the fact that someone was able to fraudulently make a change, suggesting that the account itself has been compromised; the real problem is that they have already lost control. | - Replace affirmative confirmation with notification requirement - Eliminate 60-day CoR lock for this use case | No. If domain theft is occurring, it is unrelated to the change of registrant name (which is not even the case in this example, this is a legitimate change). Other actions which may be a change of control could necessitate additional requirements, but changing the registrant name should not. | - Replace affirmative confirmation with notification requirement - Eliminate 60-day CoR lock for this use case | No. If domain theft is occurring, it is unrelated to the change of registrant name (which is not even the case in this example, this is a legitimate change) | - Replace affirmative confirmation with notification requirement - Eliminate 60-day CoR lock for this use case. Phase 1A measures are sufficient to contain risks associated with domain name hopping by delaying subsequent hops. | If a bad actor is making changes, then control has already been lost, and so that is the issue which should be addressed (not the name change). The approval and lock process causes significant disruption and dissatisfaction, without adding corresponding security value. This scenario should be considered in the context of Phase 2 deliberations on possible improvements to dispute resolution mechanisms. | |||||||||||||||
5 | Tucows (Sarah Wyld & Rich Brown) | No | No (but we are assuming for this exercise that it is known to the Rr to be illegitimate) | Not easily | Maybe. If the domain is being stolen (which we know it is, in this example, because we know this to be an illegitimate name change), the required approval of the prior registrant could alert the domain owner of a problem. However, the problem is not the name change; it is the fact that someone was able to fraudulently make a change, suggesting that the account itself has been compromised; the real problem is that they have already lost control. We believe that increased notification relating to obtaining the TAC would mitigate this risk. We further note that change to the registrant name is likely to trigger the Whois Verification process which would also notify the domain owner that the change occurred. | - Replace affirmative confirmation with notification requirement. - Eliminate 60-day CoR lock for this use case. - Consider enhancements to dispute resolution mechanisms in phase 2. | Maybe. As with the previous example, the name being changed is not the problem; if the name change is illegitimate, then control of the domain is already compromised (and THAT is the actual problem). Other security measures apply in that circumstance. | - Replace affirmative confirmation with notification requirement. - Eliminate 60-day CoR lock for this use case. - Consider enhancements to dispute resolution mechanisms in phase 2. | No. If domain theft is occurring, it is unrelated to the change of registrant name. If a bad actor is making changes to registration data, then control has already been lost by the RNH. | - Replace affirmative confirmation with notification requirement - Eliminate 60-day CoR lock for this use case. - If the name update is malicious and is followed by an inter-registrar transfer, but the email address has not been updated, the RNH will still receive all notifications about the transfer, allowing them to take action and seek remedy. | ||||||||||||||||
6 | Newfold Digital (Eric Rokobauer) | Yes | Varies | Varies | No because if the scenario is there is no change of control, the risk is lower and any registrar intervention can take place if need be. It should be noted that, it is not possible to know if there truly will be no further action taken on the domain (e.g., inter-registrar transfer) from the RNH post this change. | Eliminate consents of both registrants and replace with notification requirement to Prior Registrant Eliminate 60-day CoR lock for this use case. | No. Too restrictive as the assumption here for this use case to be a transfer of domain control where record of registrar does not change ("push"). | Eliminate consents of both registrants and replace with notification requirement to Prior Registrant Eliminate 60-day CoR lock MUST requirement for this use case. Introduce new security mechanism (managed at registrar) if domain control is moved between accounts at registrar. | No. Additional lock following a legitimate change is not necessary as the proposed 30 day lock post inter-registrar transfer will suffice | Eliminate consents of both registrants and replace with notification requirement to Prior Registrant Eliminate 60-day CoR lock MUST requirement for this use case. Phase 1A measures are sufficient to contain risks associated with domain name hopping by delaying subsequent hops. | ||||||||||||||||
7 | Newfold Digital (Eric Rokobauer) | No | Confirming if the action was illegitimate will only be prompted if a registrant contact is received and acknowledged by the registrar (through investigation or legal notice) | Not automatically, requires manually intervention | No because if the scenario is there is no change of control, the risk would be indeed lower and any registrar intervention can take place. However, it is not possible to know if there truly will be no further action taken on the domain (e.g., inter-registrar transfer) from the RNH post this change. | Eliminate consents of both registrants and replace with notification requirement to Prior Registrant Eliminate 60-day CoR lock for this use case. Consider enhancements to dispute resolution mechanisms in phase 2. | No. Too restrictive as the assumption here for this use case to be a transfer of domain control where record of registrar does not change ("push"). | Eliminate consents of both registrants and replace with notification requirement to Prior Registrant Eliminate 60-day CoR lock MUST requirement for this use case. Introduce new security mechanism (managed at registrar) if domain control is moved between accounts at registrar. | No. 60 day lock is too restrictive and confusing where there already is a lock following a inter-registrar transfer designed for a losing registrar to dispute/request reversal of the transfer. The transfer dispute process should be revamped to align with Phase 1(a) reqs, but needing this lock is redundant and should be removed. | Eliminate consents of both registrants and replace with notification requirement to Prior Registrant Eliminate 60-day CoR lock MUST requirement for this use case. Phase 1A measures are sufficient to contain risks associated with domain name hopping by delaying subsequent hops. Update and align transfer dispute process with Phase 1(a) reqs. | ||||||||||||||||
8 | Zak Muscovitch, personal capacity | Yes | Not automatically. This would of course involve manual consideration by a registrar. | Not automatically. This would of course involve manual consideration by a registrar. Even a small change, such as change of a corporate suffix from Inc. to Ltd. could signify a change of control or couldf be a correction, and would therefore be difficult for a registrar to determine even with a manual review. | I see why the are the way they are, given that there is no way to automatically determine if it is a mere typo or a substantive change. Moreover, even a manual review might not come up with the correct conclusion. | Unless it is possible to somehow conclusively determine that a change, even a minor one, is not a change of control, it should probably remain the same policy. But if it stays with the same registrar, the risks are of course lower. Perhaps if there is no change in the registrar account holder, that can be used as the determining factor to allow a change without resulting in any restriction. Nevertheless, a registrar and a registrant should be empowered to agree between themselves in circumstances that they deem appropriate, to agree to a transfer at any time despite any restriction. For example, if a registrar knows for a fact that the change is legitimate based upon its knowledge of the registrant and/or security protocols that are in place at the registrar, that should not result in any restriction. | A name change alone could constitute a legal change of control even if it is not a technical one, i.e. it remains in the same account at the registrar. | A name chance could be considered a legal change of control, no matter how minor. Nevertheless, if it stays at the same registrar account then it is less likley to be an issue. If on the other hand the change corresponds to a change of account or registrar, that is more likley to be a genuine substantive change of control. On the other hand, this is not always the case and therefore a registrar and its customer should probably be allowed to override any restriction in apprropriate circumstances in the registrar's discretion.Possible actions: Not applicable Do nothing, Notification 30-day restriction 60-day restriction Other? | Since there are many usual circumstances where an inter-regisrar transfer is subsequent to a change of registrant is completely legitimate, there should not be a resatriction that cannot be overriden in apopropriate circumstances. | Since there are many usual circumstances where an inter-regisrar transfer is subsequent to a change of registrant is completely legitimate, there should not be a resatriction that cannot be overriden in apopropriate circumstances. | ||||||||||||||||
9 | Zak Muscovitch, personal capacity | No | ||||||||||||||||||||||||
10 | MarkMonitor (Prudence Malinki) | Yes | Not easily | Judgement call in a lot of cases can vary depending on circumstances | Not really . The 60 day lock is problematic in these ciricumstances for a lot of regisrars regardless of their model | Provide noitification instead of affirmative confirmation and No 60 day lock | Not really can be streamlined as a th e change to a registrant name shouldn't really be a Change in control that is enough to be a trigger event | Although this shouldn't relaly be a Change of control- if we need to take action, there should be no lock for this category . We can use the confirmations instead | Not reaally . We have created a 30 day lock under phase 1a which should be sufficient. | Remove 60 day lock Just send notificaiton | The update of a registrant name alone should not be triggering a 60 day lock . We should either remove it entirely or reduce the period to around 30 days . A notification should be acceptable.We would prefer to hav e the lock removed completely . The phase 1a processes should be sufficient . | |||||||||||||||
11 | MarkMonitor (Prudence Malinki) | No | Not easily | Judgement call in a lot of cases can vary depending on circumstances | Not really we don’t really need a 60 day lock for this. | As above providing a notificaion of affirmative confirmation and no lock | Not really we don’t really need a 60 day lock for this. | Notificiations should be sufficinet for this. | Not quite . The lock can sometimes not actually help wihere a transfer is malicious- but we should be looking into other mechanism to support this like UDRP | Remove 60 day lock Just send notificaiton | ||||||||||||||||
12 | Identity Digital (Catherine Merdinger) | Yes | Not easily | Not easily | No, because the method of contact has not changed, having the "Losing" and "Gaining" registrants consent to the transfer would effectively result in the same person "consenting" to the change. Furthermore, in my experience, registrars often appoint themselves to be a registrant's "Designated Agent" under the policy (through their Registration Agreement, acceptance of which they track by the account or email address, neither of which has chnaged in this scenario) and only have the registrants actively involved in the COR if they have to validate new contacts. Removing this type of change from the definition of "COR" would have little to no impact on registrants and would ensure that a mere change of name would not inadvertently result in a 60 day lock on the domain. | This type of change should not require any action by the registrar under the Transfer Policy. | [I forgot what "Change of Control" means, this worksheet considers it to be a transfer between accounts within the same registrar] If a domain name changes accounts and changes only the name associated with the domain name registration, as described in Column F and G of this row, the COR process should not be implicated, provided the method of contacting the registrant remains the same. Intra-account transfers, generally, should be governed by the policies of the registrar, not ICANN. | This type of change should not require any action by the registrar under the Transfer Policy. | As noted in the earlier columns, a mere name change that is not accompanied by a change to the contact method of the registrant (email, phone, physical address) should not constitute a COR. | This type of change should not require any action by the registrar under the Transfer Policy. | ||||||||||||||||
13 | Identity Digital (Catherine Merdinger) | No | Not easily | Not easily | No, because the method of contact has not changed, having the "Losing" and "Gaining" registrants consent to the transfer would effectively result in the same person "consenting" to the change. Furthermore, in my experience, registrars often appoint themselves to be a registrant's "Designated Agent" under the policy (through their Registration Agreement, acceptance of which they track by the account or email address, neither of which has chnaged in this scenario) and only have the registrants actively involved in the COR if they have to validate new contacts. Removing this type of change from the definition of "COR" would have little to no impact on registrants and would ensure that a mere change of name would not inadvertently result in a 60 day lock on the domain. | This type of change should not require any action by the registrar under the Transfer Policy. | If a domain name changes accounts and changes only the name associated with the domain name registration, as described in Column F and G of this row, the COR process should not be implicated, provided the method of contacting the registrant remains the same. Intra-account transfers, generally, should be governed by the policies of the registrar, not ICANN. | This type of change should not require any action by the registrar under the Transfer Policy. | As noted in the earlier columns, a mere name change that is not accompanied by a change to the contact method of the registrant (email, phone, physical address) should not constitute a COR. | This type of change should not require any action by the registrar under the Transfer Policy. | ||||||||||||||||
14 | GoDaddy/Uniregistry (Keiron Tobin) | Yes | Not easily | Not easily | No. I do not believe that a name change alone is a change of control. From my perspective, there should be fewer requirements if there is no true change of control, because the risks are lower. Additional note: With the current policy language, it is difficult to tell when certain updates to the name trigger additional requirements. | - Replace affirmative confirmation with notification requirement. - Eliminate 60-day CoR lock for this use case. | Not applicable. In my view, a name change alone will rarely, if ever, constitute a "change of control" in and of itself. If there is a change of control after the name is updated, it may be appropriate for additional requirements to be triggered. | Not applicable. In my view, a name change alone will rarely, if ever, constitute a "change of control." If there is a change of control after the name is updated, it may be appropriate for additional requirements to be triggered. | No. The requirement is confusing and burdensome for registrants in the many cases that this series of actions is legitimate. Under the Phase 1A recommendations, following the inter-registrar transfer, the domain will not be able to transfer to a third registrar for 30 days. The registrant will also receive notification regarding the inter-registrar transfer. In my view, this is sufficient to contain risks associated with domain name hopping. | Eliminate 60-day CoR lock for this use case. Phase 1A measures are sufficient to contain risks associated with domain name hopping by delaying subsequent hops. | A change to the RNH's name ("Prior Registrant Name") does not warrant application of the 60 day CoR lock. The 60-day CoR lock may be helpful in this scenario where the update + inter-registrar transfer is malicious. At the same time, the impact of malicious activity may be contained, because the RNH's email address remains the same and the RNH will presumably receive email notifications of the name update and inter-registrar transfer, allowing them to take action to remedy unauthorized activity. The requirement is confusing and burdensome for registrants in the many cases that this series of actions is legitimate. The negative impact of this restriction is significant and must be weighed against potential benefits. For the scenario with Prior Registrant name is updated, such that it does not appear to be merely a typographic correction, the following should apply: - No 60-day CoR lock - No requirement for prior consent of the Prior Registrant and New Registrant - New requirement that the registrant is notified of the update This scenario should be considered in the context of Phase 2 deliberations on possible improvements to dispute resolution mechanisms. - II.A.1.1.1 and II.A.1.3.1 provisions should be reviewed as to whether they are still fit for purpose when considering any final recommendations - The title of this policy "Change of Inter-Registrant" should be reviewed if still applicable | |||||||||||||||
15 | GoDaddy/Uniregistry (Keiron Tobin) | No | Not easily | Not easily | No. I do not believe that a name change alone is a change of control. From my perspective, there should be fewer requirements if there is no true change of control, because the risks are lower. There is limited impact if a malicious actor updates the name and only the name. Once alerted of the change, the RNH can seek to remedy through dispute resolution. | - Replace affirmative confirmation with notification requirement. - Eliminate 60-day CoR lock for this use case. - Consider enhancements to dispute resolution mechanisms in phase 2. | In my view, a name change alone will rarely, if ever, constitute a "change of control" in and of iteself. If there is a change of control after the name is updated, it may be appropriate for additional requirements to be triggered. It seems unlikely that a malicious actor would first update the name and then initiate a change of control. | Not applicable. In my view, a name change alone will rarely, if ever, constitute a "change of control." If there is a change of control after the name is updated, it may be appropriate for additional requirements to be triggered. | The 60-day CoR lock is helpful in this scenario where the update + inter-registrar transfer is malicious. At the same time, the requirement is confusing and burdensome for registrants in the many cases that this series of actions is legitimate. Ultimately, I believe that there are few ways to address domain theft via policy that are not overly restrictive to legitimate activity, therefore I think the 60-day CoR lock should never be applied. If the WG comes to the conclusion that the lock is needed, registrars should be required to allow the registrant to opt out of the lock before it is applied. | Eliminate 60-day CoR lock for this use case. Phase 1A measures are sufficient to contain risks associated with domain name hopping by delaying subsequent hops. If the name update is malicious and followed by an inter-registrar transfer, but the email address has not been updated, the RNH will still receive all notifications about the transfer, allowing them to take action and seek remedy. | J. The bad actor can still opt-out of this policy which invalidates the purpose of the intention of the COR. - If a security issue is dectected by the registrar, they retain the right to apply a lock, for the duration of the investigation. | |||||||||||||||
16 | ||||||||||||||||||||||||||
17 | ||||||||||||||||||||||||||
18 | ||||||||||||||||||||||||||
19 | ||||||||||||||||||||||||||
20 | ||||||||||||||||||||||||||
21 | ||||||||||||||||||||||||||
22 | ||||||||||||||||||||||||||
23 | ||||||||||||||||||||||||||
24 | ||||||||||||||||||||||||||
25 | ||||||||||||||||||||||||||
26 | ||||||||||||||||||||||||||
27 | ||||||||||||||||||||||||||
28 | ||||||||||||||||||||||||||
29 | ||||||||||||||||||||||||||
30 | ||||||||||||||||||||||||||
31 | ||||||||||||||||||||||||||
32 | ||||||||||||||||||||||||||
33 | ||||||||||||||||||||||||||
34 | ||||||||||||||||||||||||||
35 | ||||||||||||||||||||||||||
36 | ||||||||||||||||||||||||||
37 | ||||||||||||||||||||||||||
38 | ||||||||||||||||||||||||||
39 | ||||||||||||||||||||||||||
40 | ||||||||||||||||||||||||||
41 | ||||||||||||||||||||||||||
42 | ||||||||||||||||||||||||||
43 | ||||||||||||||||||||||||||
44 | ||||||||||||||||||||||||||
45 | ||||||||||||||||||||||||||
46 | ||||||||||||||||||||||||||
47 | ||||||||||||||||||||||||||
48 | ||||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||
50 | ||||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||
52 | ||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||