- gtld-tech - lists.icann.org

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

Re: [gtld-tech] Whether registrars have to implement a RDAP service
by Michele Neylon - Blacknight Dec. 9, 2015

Dec. 9, 2015

Why on earth would we go the expense of implementing this if it’s: - temporary - we can’t use proper ACLs etc., due to gaps in the ICANN policy -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 On 07/12/2015, 9:42 p.m., "gtld-tech-bounces(a)icann.org on behalf of Roger D Carney" <gtld-tech-bounces(a)icann.org on behalf of rcarney(a)godaddy.com> wrote: >Good Afternoon, > >Thanks Francisco for providing some great context around each of these updates. > >I believe the wording in 3.1.1 will cause some confusion with the intent of this update in 2.3, with 3.1.1 stating all sponsored names whereas the intent being only thin sponsored names. > >Additionally, I would like to confirm that according to the wording in this latest draft, ICANN is suggesting that all Registrars sponsoring names in any thin registry will be obligated to create and manage code and infrastructure for a temporary RDAP server implementation that will be rendered useless and most likely be discarded once the three remaining thin TLDs are moved to thick? > > >Thanks >Roger > > >-----Original Message----- >From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias >Sent: Friday, December 04, 2015 4:57 PM >To: gtld-tech(a)icann.org >Subject: [gtld-tech] Whether registrars have to implement a RDAP service > >Dear colleagues, > >Regarding open issue I.3 Whether registrars have to implement a RDAP service. > >In section 2.3 of v12 we say that registrars MUST offer RDAP service for all "thin registrations” that they sponsor. There appears to be no benefit in requiring registrars to offer RDAP service for a thick registration. >Please note that the requirements is regarding individual registrations as opposed to TLD-wise. We included a definition for “thin registration”. > >Regards, > >-- >Francisco. >

3 2

Whether registrars have to implement a RDAP service
by Francisco Arias Dec. 7, 2015

Dec. 7, 2015

Dear colleagues, Regarding open issue I.3 Whether registrars have to implement a RDAP service. In section 2.3 of v12 we say that registrars MUST offer RDAP service for all "thin registrations” that they sponsor. There appears to be no benefit in requiring registrars to offer RDAP service for a thick registration. Please note that the requirements is regarding individual registrations as opposed to TLD-wise. We included a definition for “thin registration”. Regards, -- Francisco.

2 1

Allowing/requiring differentiated access
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding open issue I.4 Whether to require implementation of differentiated access in RDAP for gTLD Registries. In section 1.4.11 of v12 the profile allows those that have a contract provision or once there is a consensus policy to offer differentiated access. The Registry Agreement for new gTLDs and the 2013 Registrar Accreditation Agreement are clear about not allowing differentiated access when they say about the Registration Data Directory Services (a.k.a. Whois) output: "The fields specified below set forth the minimum output requirements." or "The format of responses shall contain all the elements and follow a semi-free text format outline below.” For the three legacy gTLDs that have differentiated access in their registry agreements, there are, at least two models. One model describes two levels of access (similar to Andrew's proposal shared in this list) for .tel and .cat. Another model includes four levels of access for .name. Additionally, there is a Policy Development Process (PDP) initiating on Registry Directory Services (http://gnso.icann.org/en/council/resolutions#201511) that will consider the broader issue of access to registration data, including the potential for differentiated access as described in the adopted Charter for the PDP working group (see Annex C of the Final Issues Report at https://whois.icann.org/sites/default/files/files/final-issue-report-next-g eneration-rds-07oct15-en.pdf). Given the ongoing discussions and work in the community on differentiated access, it is premature to include a requirement for all gTLDs in the RDAP Profile. For parties interested in differentiated access, we’d recommend to participate in the upcoming Registry Directory Services PDP, where a call for volunteers is expected to go out next January. I plan to forward the call for volunteers to this list when I see it. Regards, -- Francisco.

1 0

Searchabilty in the gTLD RDAP profile
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding pending issue P.3. Francisco to check if ICANN would be able to require implementation of the Boolean search capabilities using existing contractual mechanism. In v12 we removed the requirement for searchability altogether. The new gTLD registry agreement (section 1.10.1) requires searchable Whois on the web-based Whois service. With that in mind we reconsidered having any searchability requirements in the profile. Those registries that have searchable Whois provisions in their agreement, should continue to offer it in their web-based RDDS (i.e., HTMTL user friendly interface) with no requirement to offer it in RDAP. Your input is welcome. Regards, -- Francisco.

1 0

Timeline for registrars to provide their expiration date to registries
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding pending issue P.2. Francisco to check on the timeline of the requirement for registrars to provide the registrar expiration date to registries. This is addressed in the draft Thick Whois Policy that went for public comment in parallel with the draft RDAP profile. In short registrars will be required to provide this data field and registries to show it once there is an EPP extension addressing this. Regards, -- Francisco.

1 0

Whether to include requirements from the T&T policy recommendations
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding pending issue P.1. Francisco to check if we can already include the requirements from the Translation & Transliteration PDP in the profile. In v12 we did not include requirements from the Translation & Transliteration policy recommendations. T&T requirements could be added to the next release of the profile in the future. It seems too early in the policy implementation to add it to the profile (the policy recommendation was only published a few weeks ago). We should leave the policy implementation process to follow its process. Regards, -- Francisco.

1 0

What should registrars respond for non-sponsored names
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding open issue I.2 Whether registrars that are queried for a name they don't sponsor should respond with HTTP 404 as a MUST or have the option to redirect (section 3.1.2 in v06) in the gTLD RDAP profile. In section 3.1.2 of v12 we left the MUST for registrars to return an HTTP 404 for names they don’t sponsor. Registries are the authorative source of information, if a Registry says that a registrar is the sponsoring registrar, but the registrar is not sponsoring the domain, something is broken. HTTP 404 seems the most accurate way to indicate this. It is true that RDAP uses HTTP, which requires support for loop detection, however the registries do not redirect, they provide a link member as defined in the profile, therefore, the built-in HTTP loop detection mechanism might not work if the registrar offers a redirection to the registry. In any case, we are deferring changing the current draft requirements until/if there is consensus from the community to do so. Your input is welcome. Regards, -- Francisco.

1 0