IRTP - Revision history

Timo at 21:00, 6 March 2023

2023-03-06T21:00:12Z

Timo at 20:59, 6 March 2023

2023-03-06T20:59:37Z

Timo: /* New Parameters */

2020-05-22T19:12:33Z

‎New Parameters

WikiAdmin: update navigation path-> Reseller Settings > Domain Settings

2019-10-15T12:14:19Z

update navigation path-> Reseller Settings > Domain Settings

WikiAdmin: Updated the old CP2 navigation paths to new CP3 paths (Reseller Settings > Domain Settings)

2019-10-07T09:02:56Z

Updated the old CP2 navigation paths to new CP3 paths (Reseller Settings > Domain Settings)

WikiAdmin: /* I am a Reseller */

2016-12-16T20:33:54Z

‎I am a Reseller

WikiAdmin: /* I am a Reseller */

2016-12-16T20:28:55Z

‎I am a Reseller

WikiAdmin at 18:31, 30 November 2016

2016-11-30T18:31:53Z

WikiAdmin at 01:21, 25 November 2016

2016-11-25T01:21:24Z

WikiAdmin at 01:46, 19 November 2016

2016-11-19T01:46:17Z

← Older revision		Revision as of 21:00, 6 March 2023
Line 40:		Line 40:
	<div style="font-size: 160%;">ICANN New Transfer - Change of Registrant</div>		<div style="font-size: 160%;">ICANN New Transfer - Change of Registrant</div>

−	<em>The Inter-Registrar Transfer Policy (IRTP) governs domain name transfers between ICANN registrars. The new provisions in the IRTP now specifically include changes to domain ownership (changes to the registrant). This means that any time a material change to a domain name's ~~registrant~~ first name, last name, or email address occurs, a sequence of authorizations, approvals, and possibly confirmation email notices are now required for registrant information to be modified. Please keep in mind that now even small changes to a domain name registrant's first name, last name, organization, and email address may trigger the validation process. This new policy takes effect on December 1, 2016.</em>	+	<em>The Inter-Registrar Transfer Policy (IRTP) governs domain name transfers between ICANN registrars. The new provisions in the IRTP now specifically include changes to domain ownership (changes to the registrant). This means that any time a material change to a domain name registrant's first name, last name, or email address occurs, a sequence of authorizations, approvals, and possibly confirmation email notices are now required for registrant information to be modified. Please keep in mind that now even small changes to a domain name registrant's first name, last name, organization, and email address may trigger the validation process. This new policy takes effect on December 1, 2016.</em>

← Older revision		Revision as of 20:59, 6 March 2023
Line 40:		Line 40:
	<div style="font-size: 160%;">ICANN New Transfer - Change of Registrant</div>		<div style="font-size: 160%;">ICANN New Transfer - Change of Registrant</div>

−	<em>The Inter-Registrar Transfer Policy (IRTP) governs domain name transfers between ICANN registrars. The new provisions in the IRTP now specifically include changes to domain ownership (changes to the registrant). This means that any time a material change to a domain name's registrant first name, last name, or email address occurs, a sequence of authorizations, approvals, and possibly confirmation email notices are now required for registrant information to be modified. Please keep in mind that now even small changes to a domain name's ~~registrant~~ first name, last name, organization, and email address may trigger the validation process. This new policy takes effect on December 1, 2016.</em>	+	<em>The Inter-Registrar Transfer Policy (IRTP) governs domain name transfers between ICANN registrars. The new provisions in the IRTP now specifically include changes to domain ownership (changes to the registrant). This means that any time a material change to a domain name's registrant first name, last name, or email address occurs, a sequence of authorizations, approvals, and possibly confirmation email notices are now required for registrant information to be modified. Please keep in mind that now even small changes to a domain name registrant's first name, last name, organization, and email address may trigger the validation process. This new policy takes effect on December 1, 2016.</em>

@@ Line 150: / Line 150: @@
 * Designated Agent (DA) of the new registrant: '''X-CONFIRM-DA-NEW-REGISTRANT = 1'''
 * Designated Agent (DA) of the old registrant: '''X-CONFIRM-DA-OLD-REGISTRANT = 0 | 1'''
-* Opt-out of sixty (60) day transferlock: '''X-REQUEST-OPT-OUT-TRANSFERLOCK = = 0 | 1'''
+* Opt-out of sixty (60) day transferlock: '''X-REQUEST-OPT-OUT-TRANSFERLOCK = 0 | 1'''
-−
 === Command Option ===

@@ Line 112: / Line 112: @@
 ::iii.'''Module Resellers (WHMCS, AWBS, Plesk)'''. You have obtained verifiable DA status to act on behalf of the new registrant of a domain name. Since the various module platforms have not updated in response to the IRTP, you are required to do the following:
-::* Login to the Control Panel and navigate to Reseller Settings > Domain Settings. Under the "gTLD Inter-Registrar Transfer Policy" section first read the terms, implement the legal changes, and finally verify your Designated Agent status and your wish to alter the ModifyDomain command for IRTP compliance.
+::* Login to the Control Panel and navigate to Reseller Controls > Product Settings > Domain Settings. Under the "gTLD Inter-Registrar Transfer Policy" section first read the terms, implement the legal changes, and finally verify your Designated Agent status and your wish to alter the ModifyDomain command for IRTP compliance.
 ::* Whenever your customer evokes a material change of registrant, the Reseller must submit the change as the DA for the new registrant.
 ::* The prior (old) registrant will always be sent an authorization email, and they will have fourteen (14) days to confirm the change.

@@ Line 103: / Line 103: @@
 #Resellers must update their terms of service and registrant agreement to reflect the new IRTP before or on December 1, 2016.
 #Resellers must add additional terms to their registrant agreement allowing them to act as Designated Agents on behalf of their customers.
-#Resellers submitting material change of registrant requests as DA, upon request, shall provide verifiable documentation that they have obtained DA status from the respective registrant for a domain name.
+#Resellers submitting a material change of registrant requests as DA, upon request, shall provide verifiable documentation that they have obtained DA status from the respective registrant for a domain name.
-#Additonal affects on different types of resellers:
+#Additonal effects on different types of resellers:
 ::i. '''Control Panel Resellers with Sub-user Customers'''. Whenever your customer evokes a material change of registrant, an additional authorization notice will be presented to the sub-user at submission in the Control Panel, as described above in the "I am a Direct Customer and not a Reseller, how does this Policy affect me?" section.
@@ Line 112: / Line 112: @@
 ::iii.'''Module Resellers (WHMCS, AWBS, Plesk)'''. You have obtained verifiable DA status to act on behalf of the new registrant of a domain name. Since the various module platforms have not updated in response to the IRTP, you are required to do the following:
-::* Login to the Control Panel and navigate to Manage Account > My Settings > Domain Settings. Under the "gTLD Inter-Registrar Transfer Policy" section first read the terms, implement the legal changes, and finally verify your Designated Agent status and your wish to alter the ModifyDomain command for IRTP compliance.
+::* Login to the Control Panel and navigate to Reseller Settings > Domain Settings. Under the "gTLD Inter-Registrar Transfer Policy" section first read the terms, implement the legal changes, and finally verify your Designated Agent status and your wish to alter the ModifyDomain command for IRTP compliance.
 ::* Whenever your customer evokes a material change of registrant, the Reseller must submit the change as the DA for the new registrant.
-::* The prior (old) registrant will always be sent a authorization email, and they will have fourteen (14) days to confirm the change.
+::* The prior (old) registrant will always be sent an authorization email, and they will have fourteen (14) days to confirm the change.
 ::* The opt-out of the sixty (60) transfer lock is enabled for module Resellers by default.  However, if a Reseller wishes to opt-IN (disable the automatic opt-out) to the registrar transfer lock so that they can immediately process Change of Registrant requests with added security (for Change of Registrant when email addresses are not working), resellers can simply enable the checkbox stating "Disable the automatic opt-out. Registrant changes are processed in realtime, but domains will also get transfer-locked for 60 days. Dependant on fallback being enabled."

@@ Line 115: / Line 115: @@
 ::* Whenever your customer evokes a material change of registrant, the Reseller must submit the change as the DA for the new registrant.
 ::* The prior (old) registrant will always be sent a authorization email, and they will have fourteen (14) days to confirm the change.
-::* The opt-out of the sixty (60) transfer lock is always enabled for module Resellers.
+::* The opt-out of the sixty (60) transfer lock is enabled for module Resellers by default.  However, if a Reseller wishes to immediately process Change of Registrant requests and also activate a registrar transfer lock for 60 days, they can enable the checkbox stating "Disable the automatic opt-out. Registrant changes are processed in realtime, but domains will also get transfer-locked for 60 days. Dependant on fallback being enabled."
 ::iv.'''API Resellers'''. You have obtained verifiable DA status to act on behalf of the new registrant of a domain name. The registrant or the DA must have obtained prior approval to act on behalf of the new registrant, therefore, the Reseller can then submit a TradeDomain command with the following three x-flag options:

@@ Line 26: / Line 26: @@
 <td>
 <ol>
-<li>Why is there no New Registrant confirmation email?<br /><br />
+<li>Why is there no New Registrant Authorization email?<br /><br />
-For every change of registrant, the OLD registrant or the reseller must have already obtained permission from the NEW registrant.  Therefore, the Designated Agent for the New Registrant is already set.  Moreover, in terms of protection and security, the OLD registrant confirmation is the single most important factor in allowing the change of registrant, not the new one.<br />&nbsp;<br />
+For every change of registrant, the OLD registrant or the reseller must have already obtained permission from the NEW registrant.  Therefore, the Designated Agent for the New Registrant is already set.  Moreover, in terms of protection and security, the OLD registrant's authorization is the single most important factor in allowing the change of registrant, not the new one.<br />&nbsp;<br />
 </li>
 <li>
 How do these Change of Registrant notice and the ICANN Registrant Verification emails work?<br /><br />
-If the NEW registrant has not previously been verified through the ICANN Registrant Verification procedure, after the Change of Registrant has been finalized, the NEW registrant will be sent a Registrant Verification email.  Remember that a reseller must be the designated agent for the NEW registrant, therefore no change of registrant confirmation email is sent to the NEW registrant.
+If the NEW registrant has not previously been verified through the ICANN Registrant Verification procedure, after the Change of Registrant has been finalized, the NEW registrant will be sent a Registrant Verification email.  Remember that a reseller must be the designated agent for the NEW registrant, therefore no change of registrant authorization email is sent to the NEW registrant.
 </li>
 </ol>
@@ Line 106: / Line 106: @@
 #Additonal affects on different types of resellers:
-::i. '''Control Panel Resellers with Sub-user Customers'''. Whenever your customer evokes a material change of registrant, an additional confirmation notice will be presented to the sub-user at submission in the Control Panel, as described above in the "I am a Direct Customer and not a Reseller, how does this Policy affect me?" section.
+::i. '''Control Panel Resellers with Sub-user Customers'''. Whenever your customer evokes a material change of registrant, an additional authorization notice will be presented to the sub-user at submission in the Control Panel, as described above in the "I am a Direct Customer and not a Reseller, how does this Policy affect me?" section.
 ::ii. '''Control Panel Resellers Only'''. You have obtained verifiable DA status from them to act on behalf of the registrant of a domain name. This will allow the Reseller to submit a change of registrant request for their customer in the Control Panel.
@@ Line 114: / Line 114: @@
 ::* Login to the Control Panel and navigate to Manage Account > My Settings > Domain Settings. Under the "gTLD Inter-Registrar Transfer Policy" section first read the terms, implement the legal changes, and finally verify your Designated Agent status and your wish to alter the ModifyDomain command for IRTP compliance.
 ::* Whenever your customer evokes a material change of registrant, the Reseller must submit the change as the DA for the new registrant.
-::* The prior (old) registrant will always be sent a confirmation email, and they will have fourteen (14) days to confirm the change.
+::* The prior (old) registrant will always be sent a authorization email, and they will have fourteen (14) days to confirm the change.
 ::* The opt-out of the sixty (60) transfer lock is always enabled for module Resellers.
@@ Line 122: / Line 122: @@
 ::* X-CONFIRM-DA-OLD-REGISTRANT = 0 or 1
 ::*X-REQUEST-OPT-OUT-TRANSFERLOCK = 0 or 1
-#Your customers may receive a change of registrant confirmation email in which they will have fourteen (14) days to approve and complete the change of registrant. Failure to confirm a change of registrant within this time will invalidate the transaction.
+#Your customers may receive a change of registrant authorization email in which they will have fourteen (14) days to approve and complete the change of registrant. Failure to confirm a change of registrant within this time will invalidate the transaction.
 #A material change of registrant for a domain contact handle involving one or more gTLD domain names will be reflected on the Control Panel only, but will not be submitted to the registry (whois data will not change).
 #If your customers receive a change of registrant confirmation email that they were not expecting or have were not aware of, please contact our support team immediately.
@@ Line 136: / Line 136: @@
 #* X-CONFIRM-DA-OLD-REGISTRANT = 0 or 1
 #* X-REQUEST-OPT-OUT-TRANSFERLOCK = 0 or 1
-#Your customers may receive a change of registrant confirmation email in which they will have fourteen (14) days to approve and complete the change of registrant. Failure to confirm a change of registrant within this time will invalidate the transaction.
+#Your customers may receive a change of registrant authorization email in which they will have fourteen (14) days to approve and complete the change of registrant. Failure to confirm a change of registrant within this time will invalidate the transaction.
 #A material change of registrant for a domain contact handle involving one or more gTLD domain names will be reflected on the Control Panel only, but will not be submitted to the registry (whois).
 #If your customers receive a change of registrant confirmation email that they were not expecting or were unaware of, please contact us immediately.
@@ Line 235: / Line 235: @@
 === TRADEDOMAIN with OPT-OUT ===
-To avoid the sixty (60) day transferlock, you have the option to request the TradeDomain command with the additional parameter '''X-REQUEST-OPT-OUT-TRANSFERLOCK = 1'''. The activation of this parameter triggers an email. The old registrant will receive an email requesting the confirmation of the change of registrant. This email have to be approved within fourteen (14) days to complete the TRADE request and avoid the sixty (60) days transferlock.
+To avoid the sixty (60) day transferlock, you have the option to request the TradeDomain command with the additional parameter '''X-REQUEST-OPT-OUT-TRANSFERLOCK = 1'''. The activation of this parameter triggers an email. The old registrant will receive an email requesting the authorization of the change of registrant. This email have to be approved within fourteen (14) days to complete the TRADE request and avoid the sixty (60) days transferlock.
 <br><br>
 [[File:New_transfer_with_optout.png]]
@@ Line 266: / Line 266: @@
 ==Frequently Asked Questions - General==
-====What is a "Material Change of Registrant" and will even a small change, like correcting a typo, trigger the confirmation process?====
+====What is a "Material Change of Registrant" and will even a small change, like correcting a typo, trigger the new authorization and confirmation process?====
-The new ICANN transfer policy requires confirmation if there are any changes to the registrant:
+The new ICANN transfer policy requires authorization if there are any changes to the registrant:
 :* first name
@@ Line 276: / Line 276: @@
 :* administrative contact email address, only if there is no registrant email address
-Any change, even small changes, may require the confirmation process to take effect. Keep in mind that small changes likely mean that the old registrant and the new registrant are the same individual (entity), therefore, confirmation checks can be provided directly at the point of submission, as well as opting out of the sixty (60) day lock.
+Any change, even small changes, may require the authorization process to take effect. Keep in mind that small changes likely mean that the old registrant and the new registrant are the same individual (entity), therefore, authorization can be provided directly at the point of submission, as well as opting out of the sixty (60) day lock.
@@ Line 294: / Line 294: @@
 ====What if I am both the old and the new registrant?====
-Both the old and new registrant must confirm, therefore, the one registrant can confirm for both. This will bypass the confirmation email process and automatically complete the change of registrant. Opting-out of the post sixty (60) day transfer lock at submission is recommended for this scenario, which will trigger an email to the old registrant email.
+Both the old and new registrant must confirm, therefore, the one registrant can authorize for both. This will bypass the authorization email process and automatically complete the change of registrant. Opting-out of the post sixty (60) day transfer lock at submission is recommended for this scenario, which will trigger an email to the old registrant email.
-====What happens if either the old or new registrant denies confirmation?====
+====What happens if either the old or new registrant does not authorize?====
-If the old registrant does not confirm the change of registrant within fourteen (14) days, the domain name registrant information (whois data) will remain the same, that of the old registrant. The new registrant (or their DA) must always give confirmation, which is obtained by the old registrant or their DA beforehand or automatically provided by the new registrant's DA at submission
+If the old registrant does not authorize the change of registrant within fourteen (14) days, the domain name registrant information (whois data) will remain the same, that of the old registrant. The new registrant (or their DA) must always give authorization, which is obtained by the old registrant or their DA beforehand or automatically provided by the new registrant's DA at submission
-====What happens if the old registrant confirmation is not received within fourteen (14) days?====
+====What happens if the old registrant authorization is not received within fourteen (14) days?====
 The change of registrant request will be denied and a brand new change of registration request will have to be initiated.
@@ Line 384: / Line 384: @@
-====Why is there no Confirmation Email to the New Registrant?====
+====Why is there no Authorization Email to the New Registrant?====
-A reseller ''MUST ALWAYS'' act as the designated agent of the new registrant, therefore no change of registrant confirmation email is needed for the new registrant.
+A reseller ''MUST ALWAYS'' act as the designated agent of the new registrant, therefore no change of registrant authorization email is needed for the new registrant. Moreover, in terms of protection and security, the OLD registrant authorization is the single most important factor in completing the change of registrant, not the new one.
-Moreover, in terms of protection and security, the OLD registrant confirmation is the single most important factor in completing the change of registrant, not the new one.
 ====How do these Change of Registrant notice and the ICANN Registrant Verification emails work?====
-If the NEW registrant has not previously been verified through the ICANN Registrant Verification procedure, after the Change of Registrant has been finalized, the NEW registrant will be sent a Registrant Verification email.  Remember that a reseller must be the designated agent for the NEW registrant, therefore no change of registrant confirmation email is sent to the NEW registrant.
+If the NEW registrant has not previously been verified through the ICANN Registrant Verification procedure, after the Change of Registrant has been finalized, the NEW registrant will be sent a Registrant Verification email.  Remember that a reseller must be the designated agent for the NEW registrant, therefore no change of registrant authorization email is sent to the NEW registrant.

@@ Line 93: / Line 93: @@
 =====Change of Registrant Scenarios=====
-[[File:CORScenarios.png]]
+[[File:COR_Regular.png]]
 ====I am a Reseller====

@@ Line 5: / Line 5: @@
 </tr>
 <tr>
-<td colspan="2" bgcolor="#CEECF2" style="text-align:center;">'''Key Dates'''</td>
+<td colspan="2" bgcolor="#CEECF2" style="text-align:center;">'''Key Dates and Updates'''</td>
 </tr>
 <tr>