1 / 39

Policy Update

Policy Update. Agenda. Locking of a Domain Name Subject to UDRP Proceedings PDP Thick Whois PDP IRTP Part D PDP Policy & Implementation Other efforts?. Locking of a Domain Name subject to UDRP Proceedings Final Report. Final Report. Submitted on 5 July 2013

maddy
Download Presentation

Policy Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Policy Update

  2. Agenda • Locking of a Domain Name Subject to UDRP Proceedings PDP • Thick Whois PDP • IRTP Part D PDP • Policy & Implementation • Other efforts?

  3. Locking of a Domain Name subject to UDRP ProceedingsFinal Report

  4. Final Report • Submitted on 5 July 2013 • Two substantive changes in response to public comments received • 17 full consensus Recommendations intended to clarify and standardize the process for locking of a domain name subject to UDRP Proceedings 4

  5. #1 Definition of ‘lock’ – preventing any changes of registrar and registrant, without impairing resolution or preventing renewal • #2 & #9 - Removing obligation for complainant to notify the respondent at the time of filing, but add automatic extension of 4 days to response time upon request by respondent • #4 – Registrar not allowed to contact registrant until “lock’ has been applied • #5 - Requiring registrar to apply lock within 2 business days following request for verification Recommendations 5

  6. #6 – Best practice recommendation for registrars and UDRP Providers to provide means to identify opening hours / days (i.e. business days) • #7 – Requirement for registrar to confirm “lock” & verify information in response to verification request from UDRP Provider • #8 – If compliant, UDRP Provider shall notify parties of commencement no later than 3 business days (change from calendar days) • #10 – If complaint remains non-compliant, registrar shall within one business day of receipt of withdrawal notice remove the “lock” Recommendations 6

  7. #11 – UDRP Provider notifies registrant that any updates to contact information also need to be communicated by the registrant to the UDRP Provider • #12 – Notification also includes information that any changes as the result of lifting of privacy / proxy services after the “lock” has been applied, need to be reviewed by the UDRP Panel directly. (to be further reviewed as part of the privacy / proxy accreditation program) • #13 – Registrar must communicate within 3 business days to all parties the date for implementation of the decision – implement immediately after 10 business days if complainant has prevailed, after 15 business days if respondent prevails Recommendations 7

  8. #14 – In case of suspension (to agree on settlement), UDRP Provider informs the Registrar of suspension, including expected duration. If settlement is reached, “lock” needs to be removed within 2 business days. • #15 – Defined process for settlement, which includes the UDRP Provider confirming to the registrar the settlement reached. • #16 – Development of educational and information materials to assist in implementation of recommendations • #17 Creation of an Implementation Review Team to assist ICANN staff in the development of the implementation plan Recommendations 8

  9. Next Steps • GNSO Council to consider report and recommendations for adoption at Wednesday meeting • If adopted, public comment forum followed by Board consideration

  10. Thick Whois PDPPresentation of Initial Report

  11. Current Status • Published for public comment on 21 June • Public comment forum open until 14 July, followed by a reply period (4 August) • Workshop in Durban on Wednesday 17 July from 12.30 – 14.00 (see http://durban47.icann.org/node/39777)

  12. Initial Report Considers: • Response consistency • Stability • Access to Whois data • Impact on privacy & data protection • Cost implications • Synchronization / migration • Authoritativeness • Competition in registry services • Existing Whois applications • Data escrow • Registrar Port 43 Whois requirements

  13. Conclusion • The provision of thick Whois services should become a requirement for all gTLD registries, both existing and future. • Recognizes that a transition of the current thin gTLD registries would affect over 120 million domain name registrations - should be carefully prepared and implemented

  14. Next Steps • Review comments received • Finalize report for submission to the GNSO Council

  15. IRTP Part D PDPWorking Group Update

  16. Overview • Fourth and last Working Group (WG) of IRTP-related PDP series • WG started on 25 February 2013 • Community input from BC and RySG reviewed

  17. Charter Questions • a) Should reporting requirements for registries and dispute providers be developed in order to make precedent and trend information available to the community and allow reference to past cases in dispute submissions? • b) Should additional provisions be included in the Transfer Dispute Resolution Policy (TDRP) that set out how to handle disputes when multiple transfers have occurred? • c) Should dispute options for registrants be developed and implanted as part of the IRTP (currently registrants depend on registrars to initiate a dispute on their behalf)?

  18. Charter Questions • d) Should certain requirements and best practices be put into place for registrars to make information on transfer dispute resolution options available to registrants? • e) Are existing penalties for policy violations sufficient or should additional provisions/penalties for specific violations be added into the IRTP? • f) Did the universal adoption and implementation of EPP AuthInfo codes eliminate the need of Standard Forms of Authorization (FOAs)

  19. Key Issues under Discussion • Modification of Transfer Dispute Resolution Policy; its usefulness and effectiveness are subject to WG debate • Should registrant should be given direct dispute options? • Are there issues from earlier IRTP WG’s that should be revisited, given changes that have taken place?

  20. Future Milestones • Initial Report envisaged for early August 2013 • Final Report envisaged for ICANN 48 Buenos Aires • Info: www.tinyurl.com/irtphome

  21. Policy & ImplementationUpdate

  22. Proposed Charter – Key Assumptions • Policy development process are well defined • Implementation processes are less well defined • Exact delineation between policy and implementation may be difficult to define, but there is a need to establish a framework that takes relationship between the two into account • Appropriate level of multi-stakeholder participation needs to be included in all processes

  23. Proposed WG Charter – Mission WG to develop: • A set of principles that underpins any GNSO policy & implementation related discussions • A process for developing “Policy Guidance” that can be used instead of a PDP for developing policy other than “Consensus Policy” • A framework for implementation related discussions • Criteria to be used to determine whether an action should be addressed by a policy or implementation process • Further guidance on how GNSO Review Teams are expected to function and operate

  24. Proposed Charter – Objectives & Goals • Develop at a minimum an Initial and Final Recommendations Report • Recommendations may include proposed changes to the GNSO Operating Procedures and/or Bylaws • Includes recommended WG tasks, deliverables as well as questions that may be helpful for completing the work • Other sections follow GNSO Working Group Guidelines ‘standard’ language

  25. Next Steps • GNSO Council consideration of Charter • If/when adopted, formation of Working Group

  26. Further information • Proposed Charter - http://gnso.icann.org/en/drafts/policy-implementation-charter-04jul13-en.pdf • DT Workspace - https://community.icann.org/x/wiJ-Ag

  27. Other

  28. Other Projects • Translation & Transliteration PDP • IGO/INGO PDP • Purpose of Registration Data PDP • RAA PDP • Reporting and Metrics WG • Whois Survey Requirements Survey WG

  29. Questions?

  30. Annex – BackgroundLocking of a Domain Name subject to UDRP Proceedings

  31. Why is it important? • PDP limited to the subject of locking of a domain name subject to UDRP Proceedings • Currently no requirement to lock names in period between filing and commencement of proceedings • No definition of ‘status quo’which has resulted in different interpretations 31

  32. Recent Developments • Initial Report published for community input prior to Beijing • 5 submissions received – mostly in support, but some important issues raised (loss of informal response time, how to address suspension / settlement) • WG addressed comments received and finalized report in time for submission to GNSO Council in Durban 32

  33. Further Information • Final Report - http://gnso.icann.org/en/issues/locking/domain-name-final-05jul13-en.pdf • Initial Report – http://gnso.icann.org/en/issues/locking/domain-name-initial-15mar13-en.pdf • Public comment forum – http://www.icann.org/en/news/public-comment/locking-domain-name-15mar13-en.htm • WG workspace – https://community.icann.org/x/xq3bAQ 33

  34. Annex – Background InfoThick Whois PDP

  35. Why is this important? • ICANN specifies Whois requirements through the registry and registrar agreements • Registries use different services to satisfy their obligations: • ‘thin’Whois: A thin registry only stores and manages the information associated with the domain name • ‘thick’Whois: Thick registries maintain and provide both sets of data (domain name and registrant) via Whois. • ‘Thick’ Whois has certain advantages e.g. transfers, but there may be negative consequences that should be explored in order to determine whether ‘thick’ Whois should be required for all

  36. Background • WG started its deliberations in November 2012 • Created a number of sub-teams to address charter questions • Formed ad-hoc Expert Panel • Requested input from other ICANN SO/ACs & GNSO SG / C • Worked its way through input received topic by topic

  37. Additional Information • Initial Report - http://gnso.icann.org/en/issues/whois/thick-initial-21jun13-en.pdf • Public Comment Forum - http://www.icann.org/en/news/public-comment/thick-whois-initial-21jun13-en.htm

  38. Annex – Background InfoPolicy & Implementation

  39. Background • GNSO agreed to create a DT in Beijing to develop a charter for a Working Group to address issues that have been raised in the context of the recent discussions on policy & implementation that affect the GNSO • DT was formed and started its discussions on 10 June • Proposed charter submitted to GNSO Council for consideration on 5 July

More Related