Page History
...
Info | ||
---|---|---|
| ||
Audio Recording Zoom Recording Chat Transcript GNSO transcripts are located on the GNSO Calendar |
Note |
---|
Notes/ Action Items
Action Items:
Notes: Transfer Policy Review Phase 1 - Meeting #41 Tuesday, 05 April 2022 Proposed Agenda
2. Welcome & Chair updates a. Zack Muscovitch, update from the BC: Transfer Policy Locks -- short summary on three different kinds of locks. See email and below:
Post-Creation Lock Ten days is too short. Leave it at 60 days if possible. Maybe 30 days is a happy medium, but 60 days is still preferable. The longer the better from a trademark enforcement perspective as it prevents having to redo a UDRP or demand letter, and also assists with preventing registrar hopping when a registrar is asked to take enforcement proceedings against an infringing or unlawfully used domain name. There may be an issue in shortening the period from a registrar’s perspective, in that a registrar customer may take advantage of promotional / loss-leader type pricing for the initial year and then the customer moves away to another registrar. Change of Registrant Lock The default rule should be a transfer lock following a change of registrant. However, a registrar should be required in a transparent manner, to enable a registrant, upon request to opt-out of the transfer lock or to reduce the transfer lock, rather then leave it to each registrar to decide whether they will generally permit opt-outs. Nevertheless, each registrar should retain discretion as to whether to permit a transfer even if the registrant has ostensibly opted out, for security reasons. A transfer lock should not prevent registrants and businesses from effecting bona fide transfers when necessary or desirable. There should be a fact-based rationale for the determination of the length of the default transfer lock, whether it is 60 or 30 days, for example. A BC member is looking to see whether Domain Abuse Activity Reporting data can provide any insight into the appropriate length for transfer locks. Change of Registrar Lock This lock does not appear to be of significant concern as it would usually coincide with a change of registrant lock. However, a registrant should not be prevented from transferring a domain name from one registrar to another, even after a recent registrar change, unless there is another type of lock at play.
Questions/Discussion:
b. Schedule leading up to ICANN74 and production of Initial Report (see attached PDF):
3. Continue discussion on bulk use cases – see: Working document [docs.google.com]
See Auth-Info Codes Working Document [docs.google.com]: “Recommendation 9: The Working Group recommends that the TAC MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the transfer request.”
ACTION ITEM: Take to the list, starting with suggested new language from Sarah Wyld in the bulk use cases Working document [docs.google.com]and possible suggested text (in recommendations 3, 8, and 9?) that the TAC has to be unique using the phrase “randomly generated value”. ACTION ITEM: Leadership and staff to research the issue of whether changes to the extension of the expiration date after a transfer are in scope. 4. Fast Undo Procedure
5. AOB
|