Page History
...
Info | ||
---|---|---|
| ||
Chat Transcript (see Zoom recording, chat tab) GNSO transcripts are located on the GNSO Calendar |
Note |
---|
Notes/ Action Items ACTION ITEMS/HOMEWORK: Ongoing Action Items:
Action Items from 08 December: None captured. Notes:
2. Welcome and Chair Updates
3. Review of Small Team Proposal regarding Transfer Policy section I.A.3.7.1
4. Phase 1A Initial Report Public comment review – review of items not specifically tied to a recommendation: a. Other - Charter Questions and Report Text – see: gnso-TPR-P1A-pcrt-Initial-Report_Responses to CQs and Report Content_20220829.docx Comments 1-3: Discussion:
Comments 4-6: Discussion:
Comment 7—Table to next week to allow ICANN Org Compliance to add context. Comments 8-9: Discussion:
Comments 10-12: Discussion:
b. Other - Charter Questions and Report Text– see: https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review?preview=/201949311/212107993/gnso-TPR-P1A-pcrt-Initial-Report_Responses%20to%20CQs%20and%20Report%20Content_20220829.docx Staff note: Due to the length of this comment, please refer to the full text of the PDF here. Comments quoted below are included in pages 56-57. On page 38, section 3.4.2, the term "Lock" with relation to Domain Name Locking for a UDRP should be made more precise. For greater certainty (since there is a presumption of innocence until proven guilty), registrant should be able to change nameservers during a UDRP (i.e. registrar can set clientTransferProhibited, but should NOT set clientUpdateProhibited). UDRP complainants had ample opportunity to collect evidence/screenshots before a UDRP was filed, and preventing nameservers to change might have a negative impact on a registrant. e.g. suppose a domain was hacked, and the nameservers were changed to those controlled by the "hacker". A UDRP filing shouldn't prevent a registrant from fixing those nameservers (to change them to what they were before they were hacked), all while keeping the domain at the current registrar. (registrars need to have better granularity for their locks, which they might not all do all the time, particularly when there's a UDRP). . . . . . The Swim Lane seems to also incorrectly state "TAC Securely Stored" (by the registry). It's the HASH of the TAC that is securely stored (not the TAC itself that is securely stored). Discussion:
|