2. If your response requires an edit or deletion of Recommendation #3, please indicate the revised wording and rationale here.

Namecheap does not support any restrictions on the RNH to transfer the domain name to a new registrar at any time after initial registration or an inter-registrar transfer. We understand that while safeguarding the interests of registrants and registrars during the transfer process is paramount, the 30-day lock limits the registrant’s choice and freedom, which seems contrary to the intent of the Transfer Policy. When this lock was first introduced, the time period was chosen to provide protection for payment fraud- which could take weeks or months to discover. Today, payment fraud is discovered within days, if not hours. Fast and unencumbered domain transfers should be essential to the new Transfer Policy. We note that the new Transfer Policy provides for a more secure process that makes this 30-day restriction unnecessary and that improper transfers can be reversed through registrar and registry coordination.

2. If your response requires an edit or deletion of Recommendation #5, please indicate the revised wording and rationale here.

Namecheap supports the wording change proposed by the RrSG comment: The definition of the TAC implies that a TAC will be able to authorize a transfer at any time, but there are some times when the domain cannot be transferred and the TAC would not authorize the transfer in those circumstances. The RrSG provides two options for revision, for the Working Group’s consideration: Option 1 - unless ineligible: “...The TAC is required for a domain name to be transferred from one Registrar to another Registrar and when presented authorizes the transfer unless the transfer request has been determined ineligible by the registrar of record, due to reasons identified in the Transfer Policy” Option 2 - for eligible domain The TAC is required for a domain name to be transferred from one Registrar to another Registrar and, when presented for an eligible domain, authorizes the transfer.

2. If your response requires an edit or deletion of Recommendation #6, please indicate the revised wording and rationale here.

Namecheap believes that SLA is not the correct term, and proposes to support the RrSG’s comment wording change to "Required Timing for TAC Provision"

2. If your response requires an edit or deletion of Recommendation #9, please indicate the revised wording and rationale here.

Namecheap supports a wording change proposed by the RrSG’s comment: There may be cases where the Rr needs to NULL the TAC immediately and cannot wait for RNH approval in order to protect the security of the domain and prevent invalid transfer. Propose adding this text: “Rr may reset TAC to NULL without RNH agreement when in the best interests of the RNH.”

2. If your response requires an edit or deletion of Recommendation #13, please indicate the revised wording and rationale here.

Namecheap supports a wording change proposed by the RrSG’s comment: Some Registrars are currently using the "info" EPP command to confirm a TAC is valid before initiating the transfer with the registry; their business operations will be disrupted if this can no longer be done. We suggest preservation of the read-only use of the code as the status quo; using the info command to verify is not the same as actually using a TAC to initiate a transfer and so it should continue to be available even with this Recommendation being in place.

2. If your response requires an edit or deletion of Recommendation #17, please indicate the revised wording and rationale here.

Namecheap believes that the Losing FOA should be eliminated as was initially proposed by the Working Group. As stated previously in comments above, the new Transfer Policy provides for additional security mechanisms including enhanced TAC and required notifications that make Losing FOA superfluous.

2. If your response requires an edit or deletion of Recommendation #18, please indicate the revised wording and rationale here.

Namecheap does not support any restrictions on the RNH to transfer the domain name to a new registrar at any time after initial registration or an inter-registrar transfer. We understand that while safeguarding the interests of registrants and registrars during the transfer process is paramount, the 30-day lock limits the registrant’s choice and freedom, which seems contrary to the intent of the Transfer Policy. When this lock was first introduced, the time period was chosen to provide protection for payment fraud- which could take weeks or months to discover. Today, payment fraud is discovered within days, if not hours. Fast and unencumbered domain transfers should be essential to the new Transfer Policy. We note that the new Transfer Policy provides for a more secure process that makes this 30-day restriction unnecessary and that improper transfers can be reversed through registrar and registry coordination

2. If your response requires an edit or deletion of Recommendation #22, please indicate the revised wording and rationale here.

Namecheap supports a wording change proposed by the RrSG’s comment: The RrSG supports the intent of I.A.3.7.4 but suggests that further revisions should be made for clarity. The final sentence, directing the Registrar to remove the lock, is unclear because the lock has not previously been mentioned. We propose the following revision: In all cases, the objection must be provided by the Registered Name Holder on an opt-in basis. If the RNH removes this objection, then the transfer must be permitted within the standard timeframe.

2. If your response requires an edit or deletion of Recommendation #24, please indicate the revised wording and rationale here.

Namecheap supports additional Implementation Guidance proposed by the RrSG’s comment: The RrSG proposes additional Implementation Guidance for I.A.3.9.3 to make clear that a Registrar-applied inter-Registrar transfer lock is likely the ClientTransferProhibited EPP Status but a Registrar may instead prevent an inter-registrar transfer via some other method.

2. If your response requires an edit or deletion of Recommendation #34, please indicate the revised wording and rationale here.

Namecheap supports a wording change proposed by the RrSG’s comment: The RrSG proposes that the Recommendation title should not include the word “Voluntary” as this Recommendation speaks to both voluntary and involuntary full portfolio transfers.