January 2016 - gtld-tech - lists.icann.org

WHOIS Data Collection Phase 2 Cycle 2 of WHOIS Accuracy Reporting System (ARS)
by Russ Weinstein Jan. 15, 2016

Jan. 15, 2016

Dear Colleagues, Between 20 January and 17 February 2016, ICANN will be initiating a large volume of WHOIS queries of gTLD registrations as part of its WHOIS Accuracy Reporting System (ARS) project utilizing the following IP addresses to perform the WHOIS queries: IP Addresses: 192.0.32.230/31 and 192.0.47.230/31 A gTLD can expect to receive query rates of 10 queries per minute; we have accounted for RSP’s with multiple gTLD’s and will attempt to limit the queries to 10 per minute across a RSP. We kindly request and appreciate your cooperation in allowing these queries to be processed and ask that you please whitelist the IP addresses provided above. As a reminder, the WHOIS ARS project was established to perform periodic studies to assess the accuracy of the contact information in the WHOIS data, with a goal of identifying opportunities to improve the accuracy of this data over time. The project was established to implement a series of improvements recommended by the WHOIS Review Team and approved by the Board (8 November 2012) on the manner in which ICANN carries out its responsibilities regarding WHOIS. This collection of data will support the next cycle in the WHOIS ARS, Phase 2 Cycle 2, which aims to assess syntax and operability accuracy of the contact information in a gTLD WHOIS record. Accuracy will be determined with respect to the requirements of the WHOIS record’s applicable version of the Registrar Accreditation Agreement. ICANN will pull a sample of approximately 200,000 WHOIS records across the entire gTLD name space, and will then perform accuracy testing on a subsample of those records. We published a report (https://whois.icann.org/en/file/whois-ars-phase-2-cycle-1-report-syntax-and…) for Phase 2 Cycle 1 on 23 December 2015 and plan to publish a report of the findings of Phase 2 Cycle 2 in June 2016. More information about the project can be found on whois.icann.org: https://whois.icann.org/en/whoisars. Thank you for your cooperation, ICANN’s GDD Operations Team

2 2

Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
by Gannon, James-1 Jan. 8, 2016

Jan. 8, 2016

The important thing for us to remember and understand here is that we need to ensure that the broadest range of technical options are available to the policy folks on the GNSO PDP, if we artificially (in so far as something that is technically possible and available but we restrict its availability via this process) restrict any options or backload certain technical possibilities we are inadvertently pushing policy into one direction over the other. James Gannon IGM Manager – Projects & IT Security SME -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias Sent: 08 January 2016 01:49 To: Andrew Newton; Andrew Sullivan Cc: gtld-tech(a)icann.org Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars Hi Andy, Defining what should or should not be shown is probably better suited for the new Policy Development Process on Next-Generation gTLD Registration Directory Service. There is a call for volunteers (and observers) at https://www.icann.org/news/announcement-2016-01-04-en Regards, -- Francisco On 1/7/16, 2:21 PM, "gtld-tech-bounces(a)icann.org on behalf of Andrew Newton" <gtld-tech-bounces(a)icann.org on behalf of andy(a)hxr.us> wrote: >First, is it right of me to assume that commenting here is sufficient >to be considered providing feedback for this: >https://www.icann.org/public-comments/rdap-profile-2015-12-03-en ? > >I agree with the general aim and direction of this proposal. Comments in-line: > >On Thu, Nov 19, 2015 at 5:57 PM, Andrew Sullivan <asullivan(a)dyn.com> wrote: >> >> I understand the difficulty of specifying a profile where the possible >> future policy options are not known, but I believe that RDAP was >> designed with the goal of being able to deliver selectively any field >> at all depending on the identity of the querying party. Therefore, I >> think the profile could specify at least three roles: public1, >> authenticated-full, authenticated-test. >> > >I would call these authorization profiles, not authentication profiles. > >> RDAP services MUST provide a form of authentication service as >> described in RFC 7481. RDAP services MAY use any of the federated >> authentication models described in RFC 7481, section 3.2.1. >> >> RDAP services MUST provide differentiated access based on >> authorization, as described in RFC 7481, section 3.3. RDAP >> services MUST provide a minimum of three different authorized >> levels of access, called public1, authenticated-full, and >> authenticated-test. In the sections that follow, members >> appropriate to the public1 and authenticated-full roles are marked >> as appropriate to either or both. Any member not explicitly >> marked is assumed to appropriate to the authenticated-full role >> only The authenticated-test role is for testing, and is used to >> demonstrate the ability to selectively disable response for some >> field at test time. >> >> RDAP services MAY NOT implement additional differentiated >> responses based on authorization except as contemplated by ICANN >> policy or under agreement with ICANN under the RSEP process. >> >> Then, each member mentioned should be marked as "public1", >> "authenticated-full", or both. I think only the following fields are >> part of the public1 list: >> >> for domain objects: >> >> objectClassName >> ldhName >> unicodeName >> variants (all of it) >> nameservers >> publicIDs, but only when it's used for a registrar >> secureDNS >> status >> >> for nameserver objects: >> >> objectClassName >> ldhName >> unicodeName >> ipAddresses >> >> Nothing else goes in public1. I've called this public1 to make it >> clear that it is but one possible interpretation of what "public >> access" could be in the future; I'm not wedded to the name. > >I would include handle and any remarks the registrant intended for >public consumption. > >> >> Now, the final bit is to make it clear that access that is >> _un_authenticated will use the authenticated-full role until ICANN >> policy changes. >> >> The point of all this is to have differentiated role functionality >> sitting there and ready to go as soon as the ICANN policy changes, and >> to include in the RDAP deployment policy now all the mechanisms >> necessary to implement whatever policy the PDP comes up with. By >> doing it this way, the current policy can be respected while yet >> laying the ground for the just-launched PDP to do something sane. >> >> I hope this is useful. Apologies again for the long time to send it. >> If you have further questions, obviously, please don't hesitate to >> poke me. >> > >I don't know if this is the right place, but it would be nice if >something like draft-hollenbeck-weirds-rdap-openid could be >implemented as well, say 6 months after it is published as an RFC. > >-andy

1 0

FW: ICANN News Alert -- Call for Volunteers: New GNSO Policy Development Process (PDP) Working Group to Establish a Policy Framework for a Next-Generation gTLD Registration Directory Service to Replace WHOIS (Next-Gen RDS)
by Francisco Arias Jan. 5, 2016

Jan. 5, 2016

Colleagues, The below announcement may be of interest to some of you, particularly, for those interested in having differentiated access in RDAP/Whois. Regards, -- Francisco On 1/5/16, 12:29 PM, "ICANN News Alert" <communications(a)icann.org> wrote: ICANN News Alert News Alert https://www.icann.org/news/announcement-2016-01-04-en Call for Volunteers: New GNSO Policy Development Process (PDP) Working Group to Establish a Policy Framework for a Next-Generation gTLD Registration Directory Service to Replace WHOIS (Next-Gen RDS) 4 January 2016 In Brief The Generic Names Supporting Organization (GNSO) Council seeks volunteers to serve on a PDP Working Group to establish a policy framework for a next-generation gTLD Registration Directory Service (RDS) to replace WHOIS (Next-Gen RDS). The GNSO Council approved the WG's charter on 19 November 2015, tasking this PDP to address concerns with WHOIS by creating a new policy framework capable of balancing diverse interests to meet today's needs for gTLD registration data. What This Team Will Do The PDP WG will use a 3-phase process defined in the approved charter [PDF, 628 KB] to (1) establish gTLD registration data requirements to determine if and why a next-generation RDS is needed, (2) design policies that detail functions that must be provided by a next-generation RDS to support those requirements, and (3) provide guidance for how a next-generation RDS should implement those policies, coexisting with and eventually replacing WHOIS. This PDP WG will provide the GNSO Council with policy recommendations regarding the issues identified in the Final Issue Report [PDF, 1.2 MB] and as defined in the charter approved by the GNSO Council [PDF, 628 KB]. Specifically, this PDP WG is tasked with analyzing the purpose of collecting, maintaining and providing access to gTLD registration data and considering safeguards for protecting that data, determining if and why a next-generation RDS is needed to replace WHOIS, and creating policies and coexistence and implementation guidance to meet those needs. During the first phase of this PDP, the PDP WG will, at a minimum, attempt to reach consensus recommendations regarding the questions detailed in the PDP WG's charter. The PDP WG's output will then be submitted to the GNSO Council for approval of its recommendations regarding IF and WHY a next-generation RDS is needed to replace WHOIS before moving to the next phase. If the WG concludes a new policy framework is needed, this output should include requirements to be addressed by that new framework and any next-generation RDS. However, if the WG concludes the existing WHOIS system can adequately address requirements, the WG's output should confirm this and identify any necessary changes to the WHOIS policy framework. After Phase 1, if the GNSO Council confirms that a new policy framework and next-generation RDS are required, the PDP WG will then proceed to Phases 2 and 3, recommending a new consensus policy framework to satisfy requirements for a next-generation RDS established in Phase 1, along with any necessary coexistence and implementation guidance. Further detail regarding this 3-phase process and questions to be considered can be found in the PDP WG's charter. How This Team Will Work ICANN WGs use transparent, open processes. The meetings of this PDP WG will be recorded, and the recordings will be available to the public. The mailing list for the PDP WG will be archived publicly. The group will collaborate using a public workspace for draft materials and all final work products and milestones will be documented on the WG's wiki. The PDP WG is expected to follow the GNSO Working Group Guidelines [PDF, 350 KB] as well as the GNSO PDP Manual. How to participate There are two ways to volunteer: Individual Members – anyone interested can volunteer to join the PDP WG as a WG member, regardless of whether they are members of the ICANN community. Members are expected to actively contribute to mailing list conversations as well as meetings – it is anticipated that the PDP WG will at a minimum meet on a weekly basis via teleconference. Members are expected to provide essential input to the process. Members will be required to provide a Statement of Interest (SOI). Mailing list observers – for those who are merely interested in monitoring the WG's conversations, there is the possibility to sign up as a mailing list "observer" which offers read-only access to the mailing list. Mailing list observers will not be permitted to post, will not receive invitations to the various meetings or calls of the WG and will not have to complete a Statement of Interest. At any point in time, a mailing list observer can join the WG as a member simply by informing the GNSO Secretariat. In addition, there will be opportunities to provide input through public consultations and public comment processes that the PDP WG is expected to organize. How to Join If you are interested in joining the WG as an individual participant or mailing list observer, please fill in the sign up form or send the Word document [DOCX, 72 KB] filled in to the GNSO Secretariat All members and observers will be listed on the PDP WG's wiki page. Next steps In its motion, the GNSO Council directed that this call for volunteers be circulated as widely as possible in order to ensure broad representation and participation in the WG. This call will remain open until the WG convenes for the first time. At this juncture, it is anticipated that the PDP WG may convene online in late January 2015. Following that, regular online meetings will be scheduled in accordance with the PDP WG's work plan, which it is expected to develop as one of its first tasks. Further information and preparation For those interested in volunteering for this effort, you are strongly encouraged to review the following materials prior to the first meeting of the PDP WG: The Final Issue Report [PDF, 1.2 MB] The approved charter [PDF, 628 KB] Materials available at the PDP WG's wiki such as the EWG Final Report and other relevant information. Background Created in the 1980s, WHOIS began as a service to identify and contact entities responsible for the operation of a network resource on the Internet. Over the years, ICANN's requirements for gTLD domain name registration data collection, access and accuracy have undergone some important changes. Yet, after nearly 15 years of task forces, review teams, and studies, comprehensive WHOIS policy reform remains the source of long-running discussion and debate. In 2012, the ICANN Board launched the Expert Working Group on gTLD Registration Directory Services (EWG) to help redefine the purpose of gTLD registration data and consider how to safeguard the data, and to propose a model for gTLD registration directory services (RDS) to address accuracy, privacy, and access issues. Upon publication of the EWG's Final Report in June, 2014, an informal group of GNSO Councilors and ICANN Board Members collaborated to propose a Process Framework for structuring a GNSO PDP to successfully address these challenging issues. This Process Framework was adopted by the Board in 2015, along with a reaffirmation of its 2012 request for a PDP to be convened to define the purpose of collecting, maintaining and providing access to gTLD registration data. The Board also asked that the PDP consider safeguards for protecting data, using the recommendations in the EWG's Final Report as an input to, and, if appropriate, as the foundation for a new gTLD policy. In preparation for this PDP, a new Preliminary Issue Report [PDF, 1.4 MB] was published for public comment on 13 July 2015. A Final Issue Report [PDF, 1.2 MB] was subsequently published on 7 October 2015, including links to all public comments received, along with a draft charter for the PDP WG. This draft charter was approved by the GNSO Council on 19 November 2015, enabling the formation of a GNSO working group of community volunteers to progress this PDP. More information can be found on the GNSO PDP on Next-Generation gTLD Registration Directory Service (RDS) page and the WG's wiki, including the WG's charter, inputs already provided by all SG/Cs during the public comment period, and an extensive library of foundational materials to inform the WG's deliberations. In addition, the WG will reach out to all SG/Cs for feedback on any items that they believe should be considered that may not have been specifically called out in the approved charter. As this will be a complex multi-phase PDP, all those interested in helping to shape the policy framework for a next-generation gTLD RDS are encouraged to volunteer for this WG. Only with the help of the entire community can this WG achieve its goal of formally defining an appropriate purpose of gTLD registration data and establishing a new policy framework to enable permissible access to that data with improved privacy and accuracy. This message was sent to francisco.arias(a)icann.org from: ICANN News Alert | communications(a)icann.org | ICANN | 12025 Waterfront Drive Suite 300 | Los Angeles, CA 90094-2536 Email Marketing by Manage Your Subscription

1 0

gTLD RDAP profile - Issue 3 - draft-lozano-rdap-nameservers-sharing-name-00
by Gustavo Lozano Jan. 5, 2016

Jan. 5, 2016

Hello Colleagues, As you may know, the draft gTLD RDAP profile is now at public comment at: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en The draft gTLD RDAP profile describes four open issues. I uploaded an I-D (https://www.ietf.org/id/draft-lozano-rdap-nameservers-sharing-name-00.txt) in order to address issue 3 ³Multiple host objects for the same name server name² (p.16). Your feedback is welcomed and appreciated. Regards, Gustavo

1 0