- gtld-tech - lists.icann.org

FW: Registrar Expiration Date I-D
by Francisco Arias Jan. 27, 2016

Jan. 27, 2016

On 1/21/16, 11:59 AM, "Gustavo Lozano" <gustavo.lozano(a)icann.org> wrote: >Hello colleagues, > >I uploaded an I-D >(http://www.ietf.org/id/draft-lozano-ietf-eppext-registrar-expiration-date- >00.txt) in order to define an EPP extension to support the transmission of >the registrar registration expiration date from the registrar to the >registry. > >This extension is defined in order to support the ICANN Thick Whois Policy >Recommendation >(http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf) that >requires gTLD domain name registries to display the registrar registration >expiration date in the Registration Data Directory Service (e.g. Whois, >RDAP). > >Your feedback is appreciated. > >Regards, >Gustavo

19 67

Re: [gtld-tech] Registrar Expiration Date I-D
by Rob Golding Jan. 27, 2016

Jan. 27, 2016

> The problem that people claim to want to solve, however, is that > registrants are sometimes surprised at expiration because their > registrar says something's expired when the whois doesn't say that. This is already an issue for current registrants of all gtlds - when a thick registry changes the expiry date on a year after the expiry date, yet the registrant hasn't paid the registrar for the renewal :( It's usually accompanied by "but the whois says blah, so it doesn't expire until next year" > The idea is that by putting this data in the public whois, registrants > wont get surprised this way. Adding more data, especially where it could 'differ' to current data will simply be an exponential increase in registrar workload dealing with misunderstanding of whois, and benefits no-one Rob -- Rob Golding rob.golding(a)astutium.com Astutium Ltd, Number One Poultry, London. EC2R 8JR * domains * hosting * vps * servers * cloud * backups *

1 0

Re: [gtld-tech] [eppext] I-D Action: draft-lozano-ietf-eppext-registrar-expiration-date-00.txt
by Rubens Kuhl Jan. 22, 2016

Jan. 22, 2016

Francisco, It's possible that Jim and Scott were looking at https://www.icann.org/resources/pages/registrars/consensus-policies-en <https://www.icann.org/resources/pages/registrars/consensus-policies-en> to find an in-force consensus policy covering such requirement. I tried finding it there as well and failed as well... that is consistent with the information that although the policy was approved by GNSO Council and the Board (https://www.icann.org/resources/board-material/resolutions-2014-02-07-en#2.c <https://www.icann.org/resources/board-material/resolutions-2014-02-07-en#2.c>) has still not come through with its IRT (Implementation Review Team), which is why the document is still in public comment and the policy is still a draft. So, perhaps the I-D is a few weeks premature and the registries opposing it might see first whether that really becomes in-force ? I also wander what happened to the reseller information relaying, which was foreseen in the policy... Rubens > Em 21 de jan de 2016, à(s) 20:51:000, Francisco Arias <francisco.arias(a)icann.org> escreveu: > > Hi Jim, > > Please see https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-poli… <https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-poli…>, particularly section 2.1, starting on page 8. This document is in public comment at https://www.icann.org/public-comments/rdds-output-2015-12-03-en <https://www.icann.org/public-comments/rdds-output-2015-12-03-en> until 31 January. > > The draft provides a reference to the “parent” document of the aforementioned document, which is already in final form. Perhaps the reference in the draft should be to the child document? > > Regards, > > -- > Francisco > > On 1/21/16, 12:08 PM, "EppExt on behalf of Gould, James" <eppext-bounces(a)ietf.org <mailto:eppext-bounces@ietf.org> on behalf of JGould(a)verisign.com <mailto:JGould@verisign.com>> wrote: > >> Gustavo, >> >> I agree with Scott, it is not clear the relationship between the two and the relevance in the registry of maintaining this value. Can the registrar expiration date be greater then the domain expiration date, less then the domain expiration date, or completely different from the domain expiration date? The reference for the ThickWhoisPolicy is incorrect in the draft. Please provide the appropriate reference and highlight where in the Thick Whois Policy it defines the requirement for the registry to hold and display a registrar expiration date in addition to the authoritative domain expiration date. >> >> Thanks, >> >> — >> >> JG >> >> >> >> >> James Gould >> Distinguished Engineer >> jgould(a)Verisign.com <x-msg://42/jgould@Verisign.com> >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> VerisignInc.com <http://verisigninc.com/> >>> On Jan 21, 2016, at 2:52 PM, Hollenbeck, Scott <shollenbeck(a)verisign.com <mailto:shollenbeck@verisign.com>> wrote: >>> >>>> -----Original Message----- >>>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org <mailto:i-d-announce-bounces@ietf.org>] On Behalf Of >>>> internet-drafts(a)ietf.org <mailto:internet-drafts@ietf.org> >>>> Sent: Thursday, January 21, 2016 2:30 PM >>>> To: i-d-announce(a)ietf.org <mailto:i-d-announce@ietf.org> >>>> Subject: I-D Action: draft-lozano-ietf-eppext-registrar-expiration- >>>> date-00.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : Registrar Registration Expiration Date >>>> Extension Mapping for the Extensible Provisioning Protocol (EPP) >>>> Author : Gustavo Lozano >>>> Filename : draft-lozano-ietf-eppext-registrar-expiration- >>>> date-00.txt >>>> Pages : 15 >>>> Date : 2016-01-21 >>>> >>>> Abstract: >>>> This document describes an Extensible Provisioning Protocol (EPP) >>>> extension mapping for the provisioning and management of the >>>> registrar registration expiration date for domain names stored in a >>>> shared central repository. Specified in XML, this mapping extends >>>> the EPP domain name mapping. >>> >>> Gustavo, I wish this document would explain what this value actually means given that registrars are not the authoritative source of information for domain expiration dates. Could you please add some text to the Introduction that explains the purpose of the value and what it means of the context of the expiration date maintained by registries? Can they ever be different? What does it mean if they are different? Why are both needed if they are supposed to be the same? >>> >>> I'd also like to suggest that you add text to the different command descriptions to make it clear what the values represent when you're extending a renew, transfer, etc. >>> >>> Scott >>> >>> _______________________________________________ >>> EppExt mailing list >>> EppExt(a)ietf.org <mailto:EppExt@ietf.org> >>> https://www.ietf.org/mailman/listinfo/eppext <https://www.ietf.org/mailman/listinfo/eppext> >> > _______________________________________________ > EppExt mailing list > EppExt(a)ietf.org > https://www.ietf.org/mailman/listinfo/eppext

2 1

Re: [gtld-tech] WHOIS Data Collection Phase 2 Cycle 2 of WHOIS Accuracy Reporting System (ARS)
by Michele Neylon - Blacknight Jan. 22, 2016

Jan. 22, 2016

Russ Will this also impact thin registries ie. .com and .net, as this would have an impact on registrars? The wording of the email wasn’t very clear on this point. Regards Michele -- 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 From: <gtld-tech-bounces(a)icann.org<mailto:gtld-tech-bounces@icann.org>> on behalf of Russ Weinstein <russ.weinstein(a)icann.org<mailto:russ.weinstein@icann.org>> Date: Friday 15 January 2016 at 19:01 To: "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Subject: [gtld-tech] WHOIS Data Collection Phase 2 Cycle 2 of WHOIS Accuracy Reporting System (ARS) 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

5 8

Re: [gtld-tech] FW: Registrar Expiration Date I-D
by Michele Neylon - Blacknight Jan. 21, 2016

Jan. 21, 2016

Francisco Sorry, but why is this needed? What purpose does it serve? Regards Michele -- 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 21/01/2016, 21:55, "gtld-tech-bounces(a)icann.org on behalf of Francisco Arias" <gtld-tech-bounces(a)icann.org on behalf of francisco.arias(a)icann.org> wrote: > >On 1/21/16, 11:59 AM, "Gustavo Lozano" <gustavo.lozano(a)icann.org> wrote: > >>Hello colleagues, >> >>I uploaded an I-D >>(http://www.ietf.org/id/draft-lozano-ietf-eppext-registrar-expiration-date- >>00.txt) in order to define an EPP extension to support the transmission of >>the registrar registration expiration date from the registrar to the >>registry. >> >>This extension is defined in order to support the ICANN Thick Whois Policy >>Recommendation >>(http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf) that >>requires gTLD domain name registries to display the registrar registration >>expiration date in the Registration Data Directory Service (e.g. Whois, >>RDAP). >> >>Your feedback is appreciated. >> >>Regards, >>Gustavo

1 0

Draft RDAP Operational Profile for gTLD Registries and Registrars
by Francisco Arias Jan. 16, 2016

Jan. 16, 2016

Dear colleagues, As you may know, most gTLD registries and registrars have a provision in their respective agreements to implement RDAP. However, before requesting RDAP implementation, we would like your thoughts and inputs on which features, basic parameters, and objects will need to be implemented. We are calling this document the RDAP Operational Profile for gTLD Registries and Registrars. Attached you will find the first draft of the RDAP Operational Profile for gTLD Registries and Registrars (in Word and PDF formats). We are planning a session on the subject during both the ICANN meeting in Dublin and the IETF in Yokohama. Your feedback on this early document would be greatly appreciated by 9 November 2015. By then, we expect to have an updated document that we plan to publish for public comment around mid November. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN

10 25

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