- gtld-tech - lists.icann.org

FW: ICANN News Alert -- New Registration Data Directory Services Requirements for gTLD Registries, Registrars to Take Effect in February 2017
by Gustavo Lozano Aug. 1, 2016

Aug. 1, 2016

Hello Colleagues, I think that you may find this news alert of your interest. Regards, Gustavo From: ICANN News Alert <no-reply(a)external.icann.org> Reply-To: "no-reply(a)external.icann.org" <no-reply(a)external.icann.org> Date: Tuesday, July 26, 2016 at 17:34 To: Gustavo Lozano <gustavo.lozano(a)icann.org> Subject: ICANN News Alert -- New Registration Data Directory Services Requirements for gTLD Registries, Registrars to Take Effect in February 2017 > ICANN News Alert > <http://www.icann.org/> > News Alert > https://www.icann.org/news/announcement-2016-07-26-en > > New Registration Data Directory Services Requirements for gTLD Registries, > Registrars to Take Effect in February 2017 > 26 July 2016 > > ICANN today announced that gTLD contracted parties must update their > Registration Data Directory Services (RDDS) by 1 February 2017. Registries and > registrars are required to implement the new Registration Data Access Protocol > (RDAP) gTLD Profile <https://www.icann.org/rdap-gtld-profile> . Registries > must also implement the data specifications defined in the Registry > Registration Data Directory Services Consistent Labeling and Display Policy > <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> . > > The RDAP gTLD Profile and the RDDS Consistent Labeling and Display Policy are > the products of community efforts to improve the current system used to > discover who controls a domain name. This system comprises data retrieval > protocols WHOIS and a web-based version of WHOIS and databases controlled > by registries and registrars that contain domain registration information. > > ICANN has notified contracted parties that they are responsible for modifying > their systems within six months. ICANN consulted these parties when defining > the new requirements and implementation plans. > Background > The Registration Data Access Protocol was developed by the Internet > Engineering Task Force <https://ietf.org/> to eventually replace the WHOIS > protocol. This new protocol is superior to WHOIS in terms of data access > security, support for international characters, extensibility, and in the > standardization of query, response and error messages. The RDAP gTLD Profile > maps ICANN policy and contractual requirements onto technical requirements in > order to standardize directory services across gTLD contracted parties. > > The RDDS Consistent Labeling and Display Policy is a Consensus Policy > developed and adopted in accordance with ICANN Bylaws. The policy is the > result of recommendations adopted by the GNSO Council after the completion of > the Thick WHOIS Policy Development Process. The ICANN board adopted these > recommendations on 7 February 2014. > > The goal of the RDDS Consistent Labeling and Display Policy is to align the > way registries and registrars label and display registration data outputs. The > policy uses the output specifications found in the 2013 Registrar > Accreditation Agreement as the standard, thus only registries need to update > their systems. Changes might include renaming or re-ordering fields and > displaying additional data, such as registrar abuse contact information. > > For more information on these topics, visit: > * Registration Data Access Protocol gTLD Profile > <https://www.icann.org/rdap-gtld-profile> > * Registry RDDS Consistent Labeling and Display Policy > <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> > * Thick WHOIS Policy Implementation > <https://www.icann.org/resources/pages/thick-whois-2016-06-27-en> > * Policy Implementation at ICANN <https://www.icann.org/policy/implementation> > About ICANN > ICANN's mission is to help ensure a stable, secure and unified global > Internet. To reach another person on the Internet, you have to type an address > into your computer - a name or a number. That address has to be unique so > computers know where to find each other. ICANN helps coordinate and support > these unique identifiers across the world. ICANN was formed in 1998 as a > not-for-profit public-benefit corporation and a community with participants > from all over the world. ICANN and its community help keep the Internet > secure, stable and interoperable. It also promotes competition and develops > policy for the top-level of the Internet's naming system and facilitates the > use of other unique Internet identifiers. For more information please visit: > www.icann.org <https://www.icann.org/> . > > > This message was sent to gustavo.lozano(a)icann.org from: ICANN News Alert | > no-reply(a)external.icann.org | ICANN | 12025 Waterfront Drive Suite 300 | Los > Angeles, CA 90094-2536 Email Marketing by > <http://www.icontact.com/a.pl/144186> > Manage Your Subscription > <http://app.icontact.com/icp/mmail-mprofile.pl?r=23976128&l=6333&s=2VAT&m=99… > 78&c=165637>

2 1

number of characters in a domain?
by Ryan Finnesey July 23, 2016

July 23, 2016

I was hoping someone can help me confirm my research. I am correct that domains are now limited to 67 characters in length including the extension? Cheers Ryan

3 2

Re: [gtld-tech] gtld-tech Digest, Vol 39, Issue 5
by Brian Mountford July 23, 2016

July 23, 2016

Francisco, I have questions about sections 1.5.14, 1.5.16 and 2.8.2. Profile Directive 1.5.14. The domain object in the RDAP response MUST contain the following events: - An event of eventAction type registration. - An event of eventAction type expiration. - An event of eventAction type last changed. The event of eventAction type last changed MUST be omitted if the domain name has not been updated since it was created. - An event of eventAction type last update of RDAP database. Is any particular ordering preferred in the results? Expiration will probably be later than last changed and last update. Should it come before or after the last changed and last update? Profile Directive 1.5.16. Entities MUST use jCard [RFC7095] structured addresses. RFC 7095 defines two different types of structured address: 3.3.1.3. Structured Property Values The vCard specification defines properties with structured values, for example, "GENDER" or "ADR". In vCard, a structured text value consists of one or multiple text components, delimited by the SEMICOLON character. Its equivalent in jCard is a structured property value, which is an array containing one element for each text component, with empty/missing text components represented by zero-length strings. jCard Example: ["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ] Some vCard properties, for example, ADR, also allow a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. jCard Example: ["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] Which form is to be used in RDAP responses? If it is the first version (list of simple strings), what is to be done with addresses containing more than two street address lines? Profile Directive 2.8.2. Registrar object lookup using an entity search on the fn element MUST be supported. RFC 7482 3.2.3. says: XXXX is a search pattern representing the "FN" property of an entity (such as a contact, registrant, or registrar) name as specified in Section 5.1 of [RFC7483]. This is straightforward enough when referring to contacts and registrants, but I am not sure how it applies to registrars. Our database stores registrars, which have a name, and also registrar contacts, which hang off registrars, and themselves also have names. Are you asking us to search by registrar name (which we would prefer), or by registrar contact name? Thanks. Brian

2 3

Do not implement before date in CL&D and RDAP profile
by Francisco Arias July 21, 2016

July 21, 2016

Dear colleagues, As you may recall the gTLD RDAP profile and Thick Whois policy implementation – Consistent Labeling and Display (CL&D for short) are synchronized and have a proposed effective date of 1 February 2017. This means enforcement would start on that date. However, in monitoring compliance with a given policy or contractual requirement we also need time to develop our tools and be able to *not* report false compliance issues (e.g., our current tool would raise an issue if it encounters the new Whois output that is specified in CL&D). We need to update that tool to avoid that issue from happening. We’d like to add to both CL&D and the RDAP profile a “do not implement before” date to avoid the aforementioned issue. We are thinking we are going to need approximately four months to update/build our tools be able to identify the updated Whois output and RDAP output. That would give contracted parties approximately a two-month window for release before the effective. We are planning to add such a date to the documents, unless there is a reason why people think we should not. Regards, -- Francisco

6 9

gTLD RDAP profile - release candidate
by Francisco Arias June 30, 2016

June 30, 2016

Dear colleagues, I’ve attached release candidate 1 (i.e., draft final) of the gTLD RDAP profile in PDF and Office Open XML formats. This version is a redline vs the version that underwent public comment. We plan to publish the final version by the end of July. Please review and let us know if you find any glaring issues by 15 July. This version incorporates the feedback received during the public comment period we run earlier this year and this mailing list. The main changes are as follows: 1. Section 1.3.6: allow contracted parties to add fields, events, roles without further ICANN approval. 2. Section 1.4.1: clarify requirement to support queries for strings mixing A- and U-labels. 3. Section 1.5.6: clarify mapping of EPP to RDAP statuses. 4. Section 1.5.15: make registrar expiration date optional. 5. Section 1.5.23: allow contracted parties to operate RDAP test services. 6. Section 3.1.1: limit requirement for registrars to offer RDAP services for thin registrations only. 7. Section 3.1.1: clarify that registrars will only be required to offer RDAP services for thin registrations under .com, .jobs, and .net until the effective date of the Thick Whois policy. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN PGP fingerprint: 1FDE 819F 7BEC 1CB2 127E EE54 9A4D 337B D510 E397

1 0

FW: Draft Consistent Labeling & Display - Revised Policy Language
by Francisco Arias June 29, 2016

June 29, 2016

FYI On 6/29/16, 6:42 PM, "gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of Fabien Betremieux" <gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of fabien.betremieux(a)icann.org<mailto:fabien.betremieux@icann.org>> wrote: Dear IRT members, As discussed in our meeting earlier today, we have posted our revision of the Policy language for implementation of the Consistent Labeling and Display requirement on our wiki: https://community.icann.org/pages/editpage.action?pageId=52889541. It is also attached to this email for your convenience. Please note that the format of the policy, after our revision, is different from the draft we posted for public comments in December (https://www.icann.org/public-comments/rdds-output-2015-12-03-en) We believe this was necessary to address the feedback we received from the community and the IRT in terms of the linkage of the Policy with Specification 3 of the 2013 RRA and the Whois Clarifications Advisory. For instance, while the draft policy required "The labeling and display of all gTLD registries web-based RDDS output , must be consistent with: (a) Specification 3 of the 2013 Registrar Accreditation Agreement (RAA)”, the revised policy lists specific requirements such as “3. If shown, the "Registrar Registration Expiration Date" field MUST appear immediately after the "Registry Expiry Date" field." Please also note that while the Policy has changed in format, it did not change in substance in order to address the community’s feedback we received in the public comment forum. Therefore, we believe this revision does not require further public comments and can be announced by 31 July 2016 for implementation with an effective date of 1 February 2017. Please review this revised Policy language as soon as possible, ideally before Friday 8 July COB. In the meantime, we will use the opportunity of our meeting in Helsinki tomorrow (http://sched.co/7Mdw) to present and discuss this revised policy language. Thank you for your consideration Best Regards -- Fabien Betremieux Sr. Registry Services & Engagement Manager Global Domains Division, ICANN US: +1 310 463 5334 | FR: +33 7 60 09 09 40 | Skype: fabien.betremieux

1 0

Re: [gtld-tech] WG: ICANN gTLDs v2 public report
by Matthias Pfeifer | DOTZON GmbH June 16, 2016

June 16, 2016

Hello list. Can we please add the country code of the RO to the JSON output? This would be very helpful to maintain statistical research. Best, Matthias Pfeifer DOTZON GmbH - incubating name spaces Akazienstrasse 28 10823 Berlin Deutschland - Germany Tel: +49 30 49802723 Mobil: +49 (0) 172 437 40 11 Fax: +49 30 49802727 pfeifer(a)dotzon.com www.dotzon.com DOTZON GmbH Registergericht: Amtsgericht Berlin-Charlottenburg, HRB 118598 Geschäftsführer: Katrin Ohlmer Sitz der Gesellschaft: Akazienstrasse 28, 10823 Berlin Von: gtld-tech-bounces(a)icann.org<mailto:gtld-tech-bounces@icann.org> [mailto:gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org>] Im Auftrag von Eduardo Alvarez Gesendet: Dienstag, 24. Mai 2016 01:58 An: gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> Betreff: [gtld-tech] ICANN gTLDs v2 public report Dear colleagues, We are planning to release a new version in JSON format of the new gTLDs CSV report (newgtlds.csv, currently available at http://newgtlds.icann.org/newgtlds.csv) The report will list all gTLDs that have signed a Registry agreement with ICANN, including gTLDs removed from the root, with the following fields: A-label, U-label, registry operator, the contract signing date, application number, delegation date, removal date and whether the gTLD was granted Specification 13 or not. The content of the new version of the report should be helpful to browsers and other software vendors trying to make decisions on gTLDs that have signed an agreement, or amendment including Specification 13 (http://newgtlds.icann.org/en/applicants/agb/base-agreement-spec-13-proposed…) For example, https://bugzilla.mozilla.org/show_bug.cgi?id=1196364. An example and the detail of the requirements considered for this new report are available in the attached .pdf file. Please note that we are not planning on replacing or changing the current newgtlds.csv report, which will continue to be updated as usual. Your feedback is welcome. Should you wish to provide any comments, please send them to gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> by June 30, 2016. Best regards, Eduardo Alvarez Technical Services Sr. Manager ICANN

2 1

FW: T/T Call for Volunteers
by Francisco Arias June 7, 2016

June 7, 2016

0*« *H÷ *0*10 `He0ä *H÷ ÕÑContent-type: multipart/alternative; boundary="B_3548140170_878579757" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3548140170_878579757 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Colleagues, =20 The below announcement might be of interest to you. There is a call for vol= unteers for the Translation and Transliteration policy implementation, you c= an see the details in the link below. =20 Regards, =20 --=20 Francisco =20 On 6/7/16, 9:09 AM, "Brian Aitchison" <brian.aitchison(a)icann.org> wrote: =20 Hi Francisco, =20 Fabien suggested to share the T/T call for volunteers with the =E2=80=9Cgtld-tech= =E2=80=9D mailing list to attract some tech-minded people to the IRT. If you agree= , would you mind circulating the link to the announcement?=20 =20 http://gnso.icann.org/en/announcements/announcement-29may16-en.htm =20 Thanks very much and let me know of any questions, =20 Brian=20 --B_3548140170_878579757 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:schema= s-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/office/20= 04/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta name=3DTitle c= ontent=3D""><meta name=3DKeywords content=3D""><meta http-equiv=3DContent-Type conte= nt=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft Word 1= 5 (filtered medium)"><style></style></head><body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple><di= v class=3DWordSection1><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-f= amily:Calibri'>Colleagues,<o:p></o:p></span></p><p class=3DMsoNormal><span sty= le=3D'font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></p><p cla= ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:Calibri'>The below an= nouncement might be of interest to you. There is a call for volunteers for t= he Translation and Transliteration policy implementation, you can see the de= tails in the link below.<o:p></o:p></span></p><p class=3DMsoNormal><span style= =3D'font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></p><p class= =3DMsoNormal><span style=3D'font-size:11.0pt;font-family:Calibri'>Regards,<o:p><= /o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family= :Calibri'><o:p> </o:p></span></p><div><p class=3DMsoNormal><span style=3D'f= ont-size:10.5pt;font-family:Calibri;color:black'>-- <o:p></o:p></span><= /p></div><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Calibr= i;color:black'>Francisco</span><span style=3D'font-size:11.0pt;font-family:Cal= ibri'><o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt= ;font-family:Calibri'><o:p> </o:p></span></p><div><div><p class=3DMsoNorm= al>On 6/7/16, 9:09 AM, "Brian Aitchison" <<a href=3D"mailto:brian= .aitchison(a)icann.org">brian.aitchison(a)icann.org</a>> wrote:<o:p></o:p></p= ></div></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><blockquote = style=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt= ;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE= "><div><div><div><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-famil= y:Arial;color:black'>Hi Francisco,<o:p></o:p></span></p></div><div><p class=3D= MsoNormal><span style=3D'font-size:10.5pt;font-family:Arial;color:black'><o:p>=  </o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-size:= 10.5pt;font-family:Arial;color:black'>Fabien suggested to share the T/T call= for volunteers with the “gtld-tech” mailing list to attract som= e tech-minded people to the IRT. If you agree, would you mind circulating th= e link to the announcement? <o:p></o:p></span></p></div><div><p class=3DM= soNormal><span style=3D'font-size:10.5pt;font-family:Arial;color:black'><o:p>&= nbsp;</o:p></span></p></div><div><p style=3D'margin:0in;margin-bottom:.0001pt'= ><span style=3D'font-size:11.0pt;font-family:Calibri;color:black'><a href=3D"htt= p://gnso.icann.org/en/announcements/announcement-29may16-en.htm">http://gnso= .icann.org/en/announcements/announcement-29may16-en.htm</a><o:p></o:p></span= ></p></div><div><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family= :Arial;color:black'><o:p> </o:p></span></p></div><div><p class=3DMsoNorma= l><span style=3D'font-size:10.5pt;font-family:Arial;color:black'>Thanks very m= uch and let me know of any questions,<o:p></o:p></span></p></div><div><p cla= ss=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Arial;color:black'><o= :p> </o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-si= ze:10.5pt;font-family:Arial;color:black'>Brian <o:p></o:p></span></p></= div></div></div></blockquote></div></body></html> --B_3548140170_878579757-- 0t0\ tînG¡}Î¿²Kp0 *H÷ 0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert SHA2 Assured ID CA0 150604000000Z 180604120000Z010 UUS10U California10ULos Angeles1<0:U 3Internet Corporation for Assigned Names and Numbers10UFrancisco Arias0"0 *H÷ 0 œÝ-=èACÆH)¢:uUÇ ¹Œ£¢|2{39\@)ÉRnnÿ DK©a«7ŽÑáp:«mr>ÅUèjø'5'%1ýÔkß¢î ó÷& _ +žû¹+Ÿäm2¥ãÆHzÛ¯ñ¢ø(K¢&«&PÍ^-¹ÊÁóm¬|Œ¹Í±ÔÁ#ÿ¬3Ž¶ä]}¹XÊwCA'Þ®m'ßÀ[Z£IF¬m¢®GöóÅAõ+QÝ]@#Íªÿ&ãÚ Ò0±5œéÀsÒâ*3ê@âWü C¯£ò0î0U#0ç#OØ×ŒÙ?t9I2<y0UžäÜ$ì£xPNy¿¬OÀ0Uÿ00$U0francisco.arias(a)icann.org0Uÿ 0U%0++0CU <0:08 `Hýl0*0(+https://www.digicert.com/CPS0U0~0= ; 97http://crl3.digicert.com/DigiCertSHA2AssuredIDCA-g1.crl0= ; 97http://crl4.digicert.com/DigiCertSHA2AssuredIDCA-g1.crl0y+m0k0… *H÷ ÙSÖ-/K eFêõ4Û};=D¿ hÈ@õ©(RgoìÃf¹ºÆtPŠÃŒ1¯7ê!ÛHuûæRÛå_É³që4*Éäöz×ó(rù|4âû¿ŒåYgD¯=_$H£~ÚOKœÍW²OŸDá1ÉC48±mrO5bbo³ŸÖcyî¥Ã$_¯%nl¬ ÚÖæGüî0[ÒžæçÄw Ÿh6FüªC÷Ñ]X%#z^99(.önØ57QÊrM ivÑg uVm)ñøÕ~Ñ0N06 ®y`ff¹ÅŠl[ÜÍ0 *H÷ 0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert Assured ID Root CA0 131105120000Z 281105120000Z0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert SHA2 Assured ID CA0"0 *H÷ 0 Üø#?jµïÀ'y-¢C1ßÔOw€"Î>pðŸÝ'*Œ¶, ÊÝiXAíjÚcxY",+øº~É5;Vñ|B~%°#ÆE8×=Dù |`®°ZŸ;÷©ðŠcI¶AS@2œOæPzP%Eèñ¯Íÿ^ÿPóðÿœÅõœb¹ØûEmÍÅHMý&«6Eê6×_jâA ÜéÙõÆ!8<æfÕMÙFÚöÏR§};$ÃŽÁQ5ÆëÔï~ä{áDœz7àOË qäŠà,ó²s<Á°}œ«}Å}¡,Âs£ø0ô0Uÿ0ÿ0Uÿ04+(0&0$+0http://ocsp.digicert.com0Uz0x0: 8 64http://crl4.digicert.com/DigiCertAssuredIDRootCA.crl0: 8 64http://crl3.digicert.com/DigiCertAssuredIDRootCA.crl0U%0++0³U ª0Š0¢ `Hýl00(+https://www.digicert.com/CPS0d+0VRAny use of this Certificate constitutes acceptance of the DigiCert CP/CPS and the Relying Party Agreement which limit liability and are incorporated herein by reference.0Uç#OØ×ŒÙ?t9I2<y0U#0Eë¢¯ôË1-Q§§!ómÈ0 *H÷ NÔ'¹ýw~(ñ /É;>œÆ¯úQ2TkèÊÁqQ\µúàbŠ|'Ûå¢Ùö DWÄ4ms:Ö =ÞãäEk²ë%ý^9Ÿ[BöÎ`ãù VHÎ3h{Í«ðjËOX¹{]§"âWI'îŸiS:.]ÈôPNÙ°]ŽùU@fíØ»(_íLaíX(SDŒG )²lØT;uÛgx,xÆU=X2nœCM4Û{ÆBÛìŸ«aLãß!*PWÀ`¢5Õ$f7 IÏÕøe³àânÂ0·0 çàåØFþå`üð090 *H÷ 0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert Assured ID Root CA0 061110000000Z 311110000000Z0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert Assured ID Root CA0"0 *H÷ 0 ÎäC\±ó·`ùq¥®Ü&ªôÎõ 9(X`øÚ©2a<µ±(Ü z¬çyS\1*ö26vÌÞÝ<š¢ïjû!òRaß ×â±ÙþdÒ[_ùX5ŒGÍ¡6ùkÔ°8>ÁÃ3ÙØ/þ(³§ÖÃnDÀa5þYvm×ñ¢K +ÿrÚ`Ð5ÆxU ¡Ïåm ÈI|13l"éÐ2Z¢ºí9:r¡æú€ÙÕ1u®}"®?Fö(yÈ±ÚäWÄ~°ŽŠV³œ²íª§ð·Åš?Ðÿ¡ë_wO£c0a0Uÿ0Uÿ0ÿ0UEë¢¯ôË1-Q§§!ómÈ0U#0Eë¢¯ôË1-Q§§!ómÈ0 *H÷ ¢Œßâíðãrszd¿÷rfØ2äBub®ëòÕÙÞV³ÌÎ(¹ `\LXäÓ=IEX5išGêVÆy«Øgß <æž&, œ=³(÷_ÿ"âéeïàßÁgI³]ë² *ë&íxŸ}?+ó·&5m_¶I[«=%ÁÌ¶ÂñoÆúdhë-ëB·úÝbñŸPg·lœóñk67|©[mzñF`×'ŸKÎŸÃg*hßç3f¿ nócú%ml¥·a±Ò£&¡qâÃùÃQ·+Î.æP²§ú E/¢ðò100y0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert SHA2 Assured ID CA tînG¡}Î¿²Kp0 `He i0/ *H÷ 1" ¿Ir/ãSK7LÞ*ºTñJ7ô£2ûñÇ|ß 0 *H÷ 1 *H÷ 0 *H÷ 1 160607172930Z0 *H÷ 3Ë®Íáj ¡lYþËeEv·³g%Ðã²]Üíå~cÄëzKñÈ]<ŒT-ÑrÒ²"Kµ1Þ.(fŠàO*QcC[Ü¶[øú#'uB³Ð¯;ZlW9pÛÕí{ '¿W æm)W\mvÞ«3äQA ßŸú Ü#çÒà×~oÛÈž¡á0üÎ@`žâóËÔ1Ü;ÁqU·³tr!óKŸÑ%£Ìï[}içú·Ií$t¿¶?ïáY·.Tt3.iY\ßqµ Å±»ÈLÃzå'`Ü¬ C;zß/21 "

1 0

ICANN gTLDs v2 public report
by Eduardo Alvarez May 25, 2016

May 25, 2016

Dear colleagues, We are planning to release a new version in JSON format of the new gTLDs CSV report (newgtlds.csv, currently available at http://newgtlds.icann.org/newgtlds.csv) The report will list all gTLDs that have signed a Registry agreement with ICANN, including gTLDs removed from the root, with the following fields: A-label, U-label, registry operator, the contract signing date, application number, delegation date, removal date and whether the gTLD was granted Specification 13 or not. The content of the new version of the report should be helpful to browsers and other software vendors trying to make decisions on gTLDs that have signed an agreement, or amendment including Specification 13 (http://newgtlds.icann.org/en/applicants/agb/base-agreement-spec-13-proposed -06dec13-en.pdf). For example, https://bugzilla.mozilla.org/show_bug.cgi?id=1196364. An example and the detail of the requirements considered for this new report are available in the attached .pdf file. Please note that we are not planning on replacing or changing the current newgtlds.csv report, which will continue to be updated as usual. Your feedback is welcome. Should you wish to provide any comments, please send them to gtld-tech(a)icann.org <mailto:gtld-tech@icann.org> by June 30, 2016. Best regards, Eduardo Alvarez Technical Services Sr. Manager ICANN

2 2

A-label and U-label mixing - RDAP query
by Gustavo Lozano April 19, 2016

April 19, 2016

Hello colleagues, Apologies for crossposting. During the public comments period of the "Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars", https://www.icann.org/public-comments/rdap-profile-2015-12-03-en, the following comment was received: "Section 1.4.1 of the Operational Profile is inconsistent with the guidance given in RFC 7482 regarding processing of RDAP queries containing a mixture of IDN A-labels and U-labels. Per RFC 7482, ³IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels². This requirement is not only inconsistent with RFC 7482, it is also counter to the consensus of the IETF community regarding appropriate processing of IDN queries. " Another comment on the same path says: "Allowing A-labels and U-labels will be particularly unworkable for right to left languages unless the RDAP server introduces arbitrary restrictions. It is important to remember that RDAP is intended for machine-to-machine communication. Since RFC 7482 is very clear on this guidance (do not mix the two) any software client that generates this sort of query is broken. With the relative youth of the RDAP standard there is unlikely to be a large install base of software clients with said broken implementation. If ICANN is aware of a software client that has incorrectly implemented the RDAP standard and is now generating queries which combine A-labels and U-labels then ICANN should take its concerns to the IETF where such challenges are considered as part of any implementation discussion. Enshrining bad practice within the Operational Profile will result in needless future changes to the technology or additional service restrictions." The comment is related to the following section of the gTLD RDAP profile: "1.4.1 The RDAP server MUST support Internationalized Domain Name (IDN) RDAP lookup queries using A-label or U-label format [RFC 5890] for domain name and name server objects. The RDAP server MUST accept a mixture of the two (i.e. A-label and U-label format) in the same RDAP lookup query². The purpose of this message is to obtain feedback from this community regarding this issue. We believe that the following text from RFC 7482 is a requirement for the RDAP client: "IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels.". RFC7482 provides an example of why a server may receive a mixture of A-labels and U-labels in the query: "It is possible for an RDAP client to assemble a query string from multiple independent data sources. Such a client might not be able to perform conversions between A-labels and U-labels." RFC7482 gives two options to the server: "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup. In such cases, the response to be returned to the query source may not match the input from the query source. Alternatively, the server MAY refuse to process the query". We believe that the reasoning in RFC 7482 is sufficient to require gTLD RDAP servers to accept and process a query that mixes A-labels and U-labels. Question for this community: is the behavior specified in the gTLD RDAP Profile (I.e. requiring processing of queries that mixes A-labels and U-labels) consistent with RFC 7482? Your feedback is appreciated. Regards, Gustavo

4 4

ICANN 55 TechDay Agenda
by Dr Eberhard W Lisse March 6, 2016

March 6, 2016

Please find enclosed the currently final agenda. We had a cancellation this morning but fortunately we found someone prepared and ready. It'll be in the Oliveraie hall. greetings, el

1 0

Progress Report for the Verisign Labs Experiment with Federated Authentication for RDAP
by Hollenbeck, Scott Feb. 29, 2016

Feb. 29, 2016

Thank you to everyone who has taken part in the Verisign Labs experiment with federated authentication for RDAP. This is a summary of the things we've found through the end of February. Here's a link to my original description of the experiment: http://mm.icann.org/pipermail/gtld-tech/2016-February/000703.html 1. Back in January I sent a cross-area review request to the IETF OAuth mailing list: https://mailarchive.ietf.org/arch/msg/oauth/ir4Yu1U8_oM3l52j-difKKn3u8A One person volunteered to take a look. I'm still waiting for their feedback. 2. We found one issue with the OpenID Connect specification. The auth_time claim element of the ID Token is described as "a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC". We've found one implementation that represents this value as an integer, another that represents it as a float, and the two do not interoperate. We've opened issues in the GitHub repositories for both projects, but there's been no discussion. In the mean time we've patched the code we're running to make things work. 3. We found a few issues with our software implementation of RDAP, but nothing due to issues with the specifications. 3.1 We've had to fix response codes to note the difference between 404 (not found) and 501 (not implemented) responses. 3.2 Our first implementation of core RDAP omitted search functionality. We now have it implemented per RFC 7482. More interestingly, we've done some experimentation with more complex search patterns. I'll provide a more detailed description of our findings in another message at some point in the future. 4. We've integrated two identity providers in addition to the Google Gmail and Microsoft Hotmail providers described in my original note. Verisign Labs has developed an identity provider that allows us to make and test software changes (such as support for new claims) quickly as easily. We've also added support for an identity provider developed by CZ.NIC. CZ.NIC has been very helpful with debugging the interoperability issue described in point #2 above (thanks, Jaromír). We're still looking for people to both try the service as end users and/or participate in the experiment as RDAP servers operators or as identity providers. Please contact me directly for details. Scott

1 0

RDAP session in Marrakech
by Francisco Arias Feb. 25, 2016

Feb. 25, 2016

Dear colleagues, We are having a RDAP session in Marrakech on Monday, 7 March from 13:30 to 14:45 UTC. We plan to host a discussion on the open issues. The session page is at https://meetings.icann.org/en/marrakech55/schedule/mon-rdap-implementation There is going to be remote participation if you cannot make it to the meeting in person. We’d appreciate your participation. Regards, -- Francisco P.S. The session was moved from Thursday, in case you had that in your agenda.

4 6

Re: [gtld-tech] RDAP session in Marrakech
by Michele Neylon - Blacknight Feb. 25, 2016

Feb. 25, 2016

That time slot is right up against the Registrars’ meeting with law enforcement, as well as the CCWG Engagement session, so it’ll be very hard for any registrars to attend 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 24/02/2016, 23:46, "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: >Dear colleagues, > >We are having a RDAP session in Marrakech on Monday, 7 March from 13:30 to 14:45 UTC. We plan to host a discussion on the open issues. The session page is at https://meetings.icann.org/en/marrakech55/schedule/mon-rdap-implementation > >There is going to be remote participation if you cannot make it to the meeting in person. We’d appreciate your participation. > >Regards, > >-- >Francisco > > >P.S. The session was moved from Thursday, in case you had that in your agenda.

1 0

Re: [gtld-tech] Draft gTLD RDAP profile in public comment
by Francisco Arias Feb. 12, 2016

Feb. 12, 2016

Dear Colleagues, Please note that the comment period has been extended to 31 January (https://www.icann.org/public-comments/rdap-profile-2015-12-03-en) Regards, -- Francisco On 12/4/15, 10:35 AM, "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: >Dear colleagues, > >I wanted to let you know that the draft gTLD RDAP profile is now in public >comment at >https://www.icann.org/public-comments/rdap-profile-2015-12-03-en Your >input would be more than welcome. If you like to discuss in this list, we >will also take input received here into consideration. The public comment >period ends at 23:59 on 18-Jan-2016 UTC. > >The version that is for public comment takes into consideration the input >that we received from you in the list and during the in-person >discussions. Thank you for that. As you may remember there were a few open >items from those discussions, I’ll send a separate emails to explain what >we did regarding those in the current draft. > >In case it is of any help, I’ve attached a Word redline of the version we >published for public comment (v12) vs the version we shared in the list in >September (v06). > >Regards, > >-- >Francisco. >

1 2

Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server Content
by Francisco Arias Feb. 9, 2016

Feb. 9, 2016

Hi Scott, In all the cross-posting, it seems you may have left out the list where people have currently in scope doing something about this https://community.icann.org/display/gTLDRDS/Next-Generation+gTLD+Registrati… Regards, -- Francisco On 1/29/16, 5:34 AM, "weirds on behalf of Hollenbeck, Scott" <weirds-bounces(a)ietf.org on behalf of shollenbeck(a)verisign.com> wrote: >(cross-posting to multiple lists - sorry if that's inconvenient) > >So I saw a tweet from Gavin Brown (@GavinBrown) that describes how one particular search engine has indexed the RDAP server of a gTLD registry operator: > >https://twitter.com/GavinBrown/status/692718904058191872 > >This is all the more reason to work on a client authentication specification that includes support for varying responses based on client identity and authorization. I've been working on such a specification and welcome feedback on the approach: > >https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ > >It also begs the question of the need for a BCP describing operational practices for server operators. There are ways for web servers to influence or restrict crawler behavior, but what's appropriate in this context? > >Scott > >_______________________________________________ >weirds mailing list >weirds(a)ietf.org >https://www.ietf.org/mailman/listinfo/weirds

11 29

Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
by Hollenbeck, Scott Feb. 8, 2016

Feb. 8, 2016

Francisco, about a month ago I sent this message to this list: http://mm.icann.org/pipermail/gtld-tech/2016-January/000577.html You asked a few clarifying questions, which I answered. My last reply sent on 13 January: http://mm.icann.org/pipermail/gtld-tech/2016-January/000592.html I never did receive an answer to my original question: "Will those that do not be able to defer implementation until the needed "agreement provision, waiver, or Consensus Policy" terms are in place?" ? Scott

4 4

Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server Content
by Hollenbeck, Scott Feb. 8, 2016

Feb. 8, 2016

> -----Original Message----- > From: Francisco Arias [mailto:francisco.arias@icann.org] > Sent: Friday, February 05, 2016 3:53 PM > To: Hollenbeck, Scott; gtld-tech(a)icann.org > Subject: Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server > Content > > On 2/3/16, 9:40 AM, "gtld-tech-bounces(a)icann.org on behalf of > Hollenbeck, Scott" <gtld-tech-bounces(a)icann.org on behalf of > shollenbeck(a)verisign.com> wrote: > > > > >As I've said before, I want to deploy RDAP in a way that addresses the > issues we have with WHOIS. Functional equivalence provides no > significant benefit. > > Just to be clear, differentiated access is not the only benefit you get > from RDAP. I can think of at least the below benefits: > > 1. Internationalization support for registration data > 2. Standardized query, response, and error messages > 3. Standardized extensibility > 4. Supports private access to data (i.e., over HTTPS) > 5. Bootstrapping mechanism to easily find the authoritative server > for a given query > 6. Standardized redirection/reference mechanism (e.g., from a thin > registry to a registrar) > 7. Flexibility to support various policies All true, and not all to be realized "soon" given the multiple paths we're on. The current profile proposal says nothing about support for internationalized registration data. The bootstrapping mechanism doesn't work *at all* for entity queries. Thin-to-thick redirection won't be needed if/when thin registries become thick registries. Two of these (i18n and thick/thin) are still very much bound to ongoing policy work. As things are currently proposed we would get very little beyond benefits associated with HTTP and JSON-encoding. Scott

1 0

Verisign Labs Experimental Implementation of RDAP with Federated Authentication
by Hollenbeck, Scott Feb. 3, 2016

Feb. 3, 2016

I'd like to invite the members of this list to participate in an experiment that's focused on evaluating how well RDAP can be implemented with support for federated authentication using OpenID Connect. The details of the protocol specification and implementation approach are described in an Internet-Draft that I'm developing: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ The I-D might be a little too much detail for someone who just wants to try out the service, though. The easiest way to participate is to use a web browser pointed here: https://rdap.verisignlabs.com/ Please read the Internet-Draft if you're not interested in using a web browser. It describes the proposed protocol parameters and interactions with non-browser clients. Our web interface can be used to submit RDAP queries for domains, name servers, and entities registered in the .cc and .tv ccTLDs. The web form contains two elements: 1) a drop-down menu that allows you to select the type of object you wish to look up, and 2) the name of the object you wish to look up, such as "nic.tv" (with no quotes). You'll see two command buttons on the form. The "Don't Authenticate" button will submit an RDAP query without client authentication. The "Authenticate" button will start the process of submitting an authenticated RDAP query by prompting you to enter an OpenID identifier. We currently accept identifiers issued by Google (in the form of Gmail addresses) and Microsoft (in the form of Hotmail addresses). "Don't Authenticate" will return an RDAP response that contains very limited information to demonstrate how the amount of returned information can be controlled based on client identity and authorization. Successful client authentication using "Authenticate" will return more, but still not complete, information. We plan to add support for additional Identity Providers that will be authorized to return full information in the future as the experiment evolves. I'm especially interested in working with implementers who may be interested in setting up an Identity Provider and participating in the experiment. I've set up an email address that you can use to communicate with the development team. Please send questions and/or feedback to rdap-exp(a)verisign.com. The experiment's terms of use can be found here: https://rdap.verisignlabs.com/termsofuse The experiment will run until June 3, 2016. We will evaluate the results at that time and we will decide if the experiment will be extended or come to an end. We reserve the right to end the experiment at any time before then. Thank you, and please feel free to contact me directly with any questions. Scott

1 0

Search Engines Indexing RDAP Server Content
by Hollenbeck, Scott Feb. 3, 2016

Feb. 3, 2016

(cross-posting to multiple lists - sorry if that's inconvenient) So I saw a tweet from Gavin Brown (@GavinBrown) that describes how one particular search engine has indexed the RDAP server of a gTLD registry operator: https://twitter.com/GavinBrown/status/692718904058191872 This is all the more reason to work on a client authentication specification that includes support for varying responses based on client identity and authorization. I've been working on such a specification and welcome feedback on the approach: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ It also begs the question of the need for a BCP describing operational practices for server operators. There are ways for web servers to influence or restrict crawler behavior, but what's appropriate in this context? Scott

7 7

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

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

Requirements for the CA in TLS and DANE
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding open issue I.1 What requirements should be for the CA to be used in TLS or whether to use DANE in the gTLD RDAP profile In sections 1.3.3 and 1.3.4 of v12 we added a MUST for DANE support and kept the MUST for CA requirements (already in v06 of the draft). Since RDAP would be a new service it would seem ok to have requirements for not-widely implemented technologies like DANE. RDAP and DANE could grow in adoption together as RDAP is deployed. We left the MUST for the CA requirements given the current reality of support. In the future, we could consider removing the CA requirements once that support for DANE is observed in sufficient scale in RDAP. Regarding the potential issue of certain jurisdiction requiring the use of a CA that would not comply with the requirements set forth in the profile, we considered that we already have a process to address cases where a contracted party indicates that it is legally prevented by local/national laws from complying with ICANN's requirements regarding the collection, display and distribution of registration data. Such process could be used in such case to seek a waiver to the requirement. Please note that v12 in public comment is just a draft and your input is welcome. Regards, -- Francisco.

1 0

Draft gTLD RDAP profile in public comment
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, I wanted to let you know that the draft gTLD RDAP profile is now in public comment at https://www.icann.org/public-comments/rdap-profile-2015-12-03-en Your input would be more than welcome. If you like to discuss in this list, we will also take input received here into consideration. The public comment period ends at 23:59 on 18-Jan-2016 UTC. The version that is for public comment takes into consideration the input that we received from you in the list and during the in-person discussions. Thank you for that. As you may remember there were a few open items from those discussions, I’ll send a separate emails to explain what we did regarding those in the current draft. In case it is of any help, I’ve attached a Word redline of the version we published for public comment (v12) vs the version we shared in the list in September (v06). Regards, -- Francisco.

1 0

gTLD RDAP Profile discussion at Yokohama
by Francisco Arias Nov. 4, 2015

Nov. 4, 2015

Colleagues, I’ve attached the slides from today’s (4-Nov) session on the gTLD RDAP profile. Thank you all of you that attended either in person or remotely. Please see below my notes and let me know if I missed or misrepresented something. We agreed to: A.1 Change 1.3.2 to have HTTPS as a MUST and as requirement in the bootstraping, but allow HTTP as optional A.2 Clarify requirement in 2.8.3 re: bootstrapping and 1.3.6 re: requirement for IPv4 and IPv6 transport A.3 Change 1.4.1 to allow queries with mixed A-label and U-label IDNs A.4 Remove requirements in 1.4.4 and 1.4.5 about blank spaces and newlines A.5 Keep the requirement in 2.8.2 regarding caching or issue re: change of the bootstrapping entry A.6 Keep requirement in 1.3.4 to register RDAP extensions before using them A.7 Keep requirement in 1.4.3 to maintain the case of the data as received in EPP A.8 Keep the "last update DB" item described in 1.4.12 as a new event type A.9 Keep the requirement in 1.5.2 to include U-label format of IDN in response A.10 Fix requirements regarding thin registry's for fields to be included in 1.5.8 and through the profile A.11 Keep the requirement in 1.5.14 to show the registrar expiration date A.12 Clarify language in 1.5.17 regarding requirement to show only allocated variants A.13 Keep requirement in section 1.5.18 to use a remarks member with title "EPP Status Codes" A.14 Clarify requirement in 1.5.19 regarding the secureDNS member to be shown if stored by the registry or registrar A.15 Remove the requirement for Boolean search capabilitiesout until there is an RFC. Once there is an RFC, ICANN should be able to require implementation using existing contractual mechanism (Francisco to confirm) A.16 The behavior for responses for multiple host objects (section 2.3) should be specified in a RDAP extension A.17 Keep the re:related mechanism in section 2.4 for the registry to refer to the registrar (no need to specify it in a RDAP extension) A.18 Clarify text in 2.9.1 as requested A.19 Have the EPP status "ok" mapped to "active" in the profile We have the following open issues: I.1 What requirements should be for the CA to be used in TLS or whether to use DANE 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) I.3 Whether registrars have to implement a RDAP service I.4 Whether to require implementation of differentiated access in RDAP for registries Other pending issues: P.1. Francisco to check if we can already include the requirements from the Translation & Transliteration PDP in the profile P.2. Francisco to check on the timeline of the requirement for registrars to provide the registrar expiration date to registries P.3. Francisco to check if ICANN would be able to require implementation of the Boolean search capabilities using existing contractual mechanism Regards, -- Francisco.

1 0

RDAP Port 43 Value
by Brian Mountford Nov. 3, 2015

Nov. 3, 2015

RFC 7483, section 4.7 talks about the port43 member, which is supposed to name the WHOIS server where the object can be found. As a registry, are we supposed to set this value to our WHOIS server, or to the registrar's? The WHOIS protocol has a similar field, which is supposed to be the registrar's server. But that takes the form of a URL, whereas RDAP port43 is explicitly not a URL. So I'm not sure what we are to put in the field, and I couldn't find any directives in the profile document. Thanks. Brian

1 0

Re: [gtld-tech] [weirds] gTLD RDAP profile meeting during IETF94
by Francisco Arias Nov. 3, 2015

Nov. 3, 2015

Dear colleagues, We have room 419 in the IETF venue from 9:00 - 12:00 on Wednesday, 4-Nov (local time). Anyone interested in discussing the draft gTLD RDAP profile is welcome. Feel free to circulate this. Regards, -- Francisco. On 10/14/15, 5:18 PM, "weirds on behalf of Gustavo Lozano" <weirds-bounces(a)ietf.org<mailto:weirds-bounces@ietf.org> on behalf of gustavo.lozano(a)icann.org<mailto:gustavo.lozano@icann.org>> wrote: Hello, [Apologies if you receive multiple copies of this email] Are you interested in meeting during IETF94 in order to discuss the gTLD RDAP profile (see http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html)? If there is enough interest, I could request a room. Remote participation would be provided if there is interest. Regards, Gustavo

1 1

Re: [gtld-tech] gtld-tech Digest, Vol 30, Issue 23
by Brian Mountford Oct. 30, 2015

Oct. 30, 2015

And is weirds(a)ietf.org a list I would need to join somehow, akin to this list? Or do I just send a message? On Fri, Oct 30, 2015 at 8:00 AM, <gtld-tech-request(a)icann.org> wrote: > Send gtld-tech mailing list submissions to > gtld-tech(a)icann.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/gtld-tech > or, via email, send a message with subject or body 'help' to > gtld-tech-request(a)icann.org > > You can reach the person managing the list at > gtld-tech-owner(a)icann.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gtld-tech digest..." > > > Today's Topics: > > 1. RDAP Questions (Brian Mountford) > 2. Re: RDAP Questions (Andrew Sullivan) > 3. Re: [weirds] gTLD RDAP profile meeting during IETF94 > (Francisco Arias) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Oct 2015 17:49:12 -0400 > From: Brian Mountford <mountford(a)google.com> > To: gtld-tech(a)icann.org > Subject: [gtld-tech] RDAP Questions > Message-ID: > <CALRmJyhCro= > HEU11DsQxzaZAJn30uJt5wjM_q2hJT58w2+KdXg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Is this a forum for questions about RDAP specifically (as opposed to the > ICANN profile regarding RDAP)? Or should I direct those questions > elsewhere? Thanks. > > Brian >

2 1

RDAP Questions
by Brian Mountford Oct. 29, 2015

Oct. 29, 2015

Is this a forum for questions about RDAP specifically (as opposed to the ICANN profile regarding RDAP)? Or should I direct those questions elsewhere? Thanks. Brian

2 1

RDAP Policy Questions
by Brian Mountford Oct. 27, 2015

Oct. 27, 2015

Hello all. I have some questions about the ICANN policy document, directives 1.5.16 and 2.1. I couldn't find existing answers in the archive of this list, so I thought I would ask. As a general matter, should I also ask my RDAP-only questions here (as opposed to the issues specifically related to ICANN policy)? Or is there another forum for such questions? Brian -------------------------------------------------- *1.5.16. Entities MUST use jCard [RFC7095] structured addresses.* RFC 7095 defines two different types of structured address: one with the street address lines concatenated into one string, and one with a subarray for the street address. It says: 3.3.1.3. Structured Property Values The vCard specification defines properties with structured values, for example, "GENDER" or "ADR". In vCard, a structured text value consists of one or multiple text components, delimited by the SEMICOLON character. Its equivalent in jCard is a structured property value, which is an array containing one element for each text component, with empty/missing text components represented by zero-length strings. jCard Example: ["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ] Some vCard properties, for example, ADR, also allow a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. jCard Example: ["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] Which form is to be used in RDAP responses? If the first version (list of simple strings, with the street lines concatenated), what is to be done with addresses containing more than two street address lines? -------------------------------------------------- *2.1. Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities. Entities MUST be searchable by name search pattern as defined in RFC7482 section 3.2.3 in order to allow for searches by contact name or address. Boolean search capabilities (AND, OR) MUST be supported, when a RFC defining this capability has been published.* Domain and entity searches are specifically mentioned, but nameserver searches are not. Does that mean that registries need not support nameserver search? Or was that an oversight? RFC 7482 does not cover entity search by address, only by name or handle. Is ICANN requiring support for an additional way to search for entities? What would the syntax of such a search be?

3 5

2nd Call for Presentations for TechDay at ICANN Dublin
by Dr Eberhard W Lisse Oct. 16, 2015

Oct. 16, 2015

We have space for one more 20 minute presentation at Tech Day in Dublin. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

3 4

gTLD RDAP profile meeting during IETF94
by Gustavo Lozano Oct. 16, 2015

Oct. 16, 2015

Hello, [Apologies if you receive multiple copies of this email] Are you interested in meeting during IETF94 in order to discuss the gTLD RDAP profile (see http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html)? If there is enough interest, I could request a room. Remote participation would be provided if there is interest. Regards, Gustavo

6 5

RDAP Features Missing from the Draft Profile Related to Current Policy Initiatives
by Hollenbeck, Scott Oct. 13, 2015

Oct. 13, 2015

Others have shared comments on the RDAP features described in the draft operational profile. I'd like to address features that aren't mentioned in the profile that could help address known operational issues with WHOIS. At least some of these should be given serious consideration in order to take advantage of the opportunity we have to address WHOIS issues as part of a transition to RDAP. In RFC 7482 I described a number of issues with the WHOIS protocol that RDAP was designed to address, including: o lack of standardized command structures; o lack of standardized output and error structures; o lack of support for internationalization and localization; and o lack of support for user identification, authentication, and access control. The profile addresses the need for standardized command structures, output structures, and error structures. It is incomplete in terms of support for internationalization/localization, user identification, authentication, and access control. There are a number of active WHOIS-related policy efforts that can produce RDAP implementation requirements. It's not unreasonable to require implementation changes to add new features as these efforts produce results, but I'd like to avoid having to undo or remove features driven by policies that may be in conflict with the current profile proposal. Examples: Expert Working Group on gTLD Directory Services (EWG) https://community.icann.org/pages/viewpage.action?pageId=40175189 The EWG (of which I was a member) produced a lengthy final report that includes a number of recommendations that were intended to address many of the issues associated with WHOIS. The final report included a number of recommendations focused on data privacy. As-is, the profile perpetuates the WHOIS "all data available to everyone" policy. I'd very much prefer to start with a more limited approach to data access that can be broadened as we decide how best to implement the RDAP features that provide identification, authentication, authorization, and access control security services. Thick WHOIS: http://gnso.icann.org/en/group-activities/active/thick-whois The profile describes a number of features that assume implementation of a "thick" registry. Two large top-level domain registries (.com and .net) are currently "thin" registries. There's still work to be done to determine how best to implement RDAP as the thick vs. thin policy discussion evolves. I would not want to be required to implement thick WHOIS knowing that there is a looming RDAP transition requirement. I am also a little concerned about the possibility of being required to implement thick RDAP without a thorough understanding of how it works in the evolving world of laws focused on protecting personally identifiable information (PII). It would be helpful if the profile included proposed implementation requirements for thin registries. WHOIS Policy Review Team https://community.icann.org/display/whoisreview/WHOIS+Policy+Review+Team This team published its final report in May 2012. Among other things, the recommendations documented in the report address data accuracy and internationalized domain names (IDNs) and internationalized registration data. If we assume that issues with data accuracy are at least somewhat associated with current WHOIS requirements for public disclosure of PII, it may be wise to consider inclusion of RDAP security services that can be used to protect against unauthorized disclosure of PII. Draft Final Report from the Expert Working Group on Internationalized Registration Data https://gnso.icann.org/en/issues/ird/ird-draft-final-10mar15-en.pdf The profile includes provisions for the representation of IDNs as either A-labels or U-Labels. It doesn't describe requirements to return responses containing internationalized registration data. Noting that internationalized registration data is referenced in Appendix E, it would be helpful to note that such requirements are being deferred (assuming that they are indeed being deferred and were not inadvertently omitted). Scott

1 0

Verisign Engineering Comments Re: Draft RDAP Operational Profile for gTLD Registries and Registrars
by Hollenbeck, Scott Oct. 12, 2015

Oct. 12, 2015

The Verisign Engineering team that is responsible for implementing RDAP in our production environment has reviewed the draft operational profile. Their comments are included below. Scott ---------- Verisign has read the proposed RDAP Profile and we have comments on the following sections. In addition to the commentary on the items addressed in the profile, we wish to express our hope that the profile will be expanded to address authentication and authorization. Merely replacing existing port43 WHOIS with JSON-formatted data misses an opportunity to improve upon deficiencies in WHOIS. Respectfully, Verisign Follow-up to publication of ICANN's RDAP profile: 1.3.2: "The RDAP service MUST be provided only over HTTPS. The TLS certificate used for the RDAP service must be issued by a Certificate Authority (CA) trusted by major browsers and mobile OS such as the ones listed in the Mozilla Included CA Certificate List (https://wiki.mozilla.org/CA:IncludedCAs) The CA, the certificate and its usage MUST follow the CAB Forum Baseline Requirements (https://cabforum.org/baseline-requirements-documents) The RDAP service MUST use the best practices for secure use of TLS as described in RFC7525 or its successors." Comment: The above seem to be guidelines missing specifics. Is the certificate used by the RDAP service domain-validated or organization-validated? What ciphers should be supported? 1.3.4/1.3: "RDAP extensions, if used, MUST be registered in the IANA's RDAP Extensions registry (https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml) as defined in RFC7480. Deployment of RDAP extensions in gTLD Registries operated under agreement with ICANN, are subject to approval by ICANN via the RSEP process." Comment: The above is contrary to the implication from Sec 2.1 of RFC 7483 that "Clients of these JSON responses SHOULD ignore unrecognized JSON members in responses" - this definitely indicates that unregistered or new RDAP extensions may be used without being formally registered as an RDAP extension. We believe it appropriate to change the "MUST" in this section to "SHOULD". One benefit of defining the RDAP protocol is extensibility, and this profile shouldn't be unnecessarily restrictive. 1.4.3: "The case (i.e. uppercase and lowercase) of the data returned in RDAP responses MUST be preserved." Comment: It is unclear where the original input of the data returned in RDAP response was derived from - are we referring to the EPP data sent by registrars during registration or is the reference specifically for the capitalization mode used in the RDAP request. Why is this a requirement? 1.4.12: "RDAP responses MUST contain the last update date and time of the database used to generate the RDAP responses (RDAP database in this document) when an RFC defining this capability has been published. The RDAP database MUST include the registration data in the SRS database. The RDAP database must be updated within the allowed Service Level Requirement (SLR) (e.g. RDDS update time, ≤ 60 minutes). In a case where the contracted party is querying its SRS database directly, and therefore, using real-time data, this date and time will show the timestamp of the response to the query." Comment: We suggest that this be specified with a new field such as "icann_db_timestamp" encoded in the top-level object instead of defining a new event. 1.5.2: "The top-level domain object in the RDAP response MUST contain the U-label format of the domain in the unicodeName member [RFC7483], only if the domain name is an IDN." Comment: For an IDN domain name, specifying 2 different encodings in the same response seems redundant and leads to wasted bandwidth. Why is the a-label not sufficient? 1.5.8: "The domain object in the RDAP response MUST contain entities with the following roles, exactly one entity per role MUST be present in the response, each of them with a handle" Comment: This seems to suggest that a prerequisite for implementing RDAP is that the top-level domain (TLD) contain "thick" registry data. That would seem to preclude the deployment of .COM and .NET RDAP services till the registries are fully converted into "thick" registries. 1.5.14: "The domain object in the RDAP response MUST contain the following events:...An event with the expiration date of the Registrar, when a RFC defining this capability has been published" Comment: Is this meant to apply to registries? Domains at the registry typically auto-renew so they usually do not expire. If it does not apply to registries, this requirement should be moved to Section 3. If it does apply, this implies that a change in the EPP specification is required before the registry can derive this information for the domain. 1.5.17: "If allocated variant domain names exist for the queried domain name or if the domain name is an allocated variant domain name, the domain object in the RDAP response MUST contain a variants member [RFC7483]. The variants relation member MUST contain valid variant relation types as defined in the IANA's RDAP JSON Values registry. If the queried domain name is an allocated variant name, the original name MUST be included in the variants member." Comment: The first sentence of this item is unclear. Is the intent that a queried (and allocated) domain having possible variants provide *allocated* variants in the reply? Is the intent that queried names that are variants of an allocated domains produce a domain response with the allocated name as the domain object? The expected behavior should be clarified through examples. 1.5.18: "A domain name RDAP response MUST contain a remarks member with a title "EPP Status Codes", a description containing the string "For more information on domain status codes, please visit https://icann.org/epp" and a links member with the https://icann.org/epp URL." Comment: Should the status definitions be defined on a top-level object instead of using a "remarks" member? This could be handled much like the suggestion for 1.4.12, with an "icann_" prefix. 1.5.19: "The domain object in the RDAP response MUST contain a secureDNS member [RFC7483] including at least a delegationSigned element. Other elements (e.g. dsData, maxSigLife) of the secureDNS member MUST be included, if the domain name is signed and the elements are known by the server." Comment: The above is ambiguous - what exactly is meant by "known to the server"? This phrasing should be changed to "stored by the registry or registrar". 2.1: "Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities. Entities MUST be searchable by name search pattern as defined in RFC7482 section 3.2.3 in order to allow for searches by contact name or address. Boolean search capabilities (AND, OR) MUST be supported, when a RFC defining this capability has been published." Comment: We believe the purpose of this profile is to define expected behaviors of a complaint RDAP implementation for registries and registrars. It should not mandate compliance with some future, yet-to-be defined RFC and, therefore, the reference to boolean search should be removed. 2.3: "If a Registry supports multiple host objects with the same name, the Registry MUST support the capability to respond with a set of host objects in response to a name server lookup, when an RFC defining this capability has been published." Comment: As with 2.1, the purpose of the profile is to define expectations of conforming registries and registrars, not mandate compliance with undefined requirements. 2.4: "The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL of the queried domain object." This requirement is unclear. A domain lookup response will contain a domain object, potentially having links to other objects, including a link back to the domain object itself. The "rel" element is optional in the RFC for good reason; if it's to be required, then the value should be either "self" or "related" depending on whether the link is back to the queried domain object, or to a related object. Regardless, the mandate for such an element is unnecessary and therefore questionable. 2.9.1: "Entity RDAP queries (registrar queries): The returned RDAP response MUST be an entity with registrar role, with a handle (IANA Registrar ID) and valid elements fn, adr, tel, email. Registrar object lookup using an entity search on the fn element MUST be supported." The above implies that Entities are only registrars which conflicts with the RFC definition of Entities as Contacts AND Registrars. It is also not stated that a Registry may only provide information on Registrars that are contracted to resell domains of a specific TLD - this list is not necessarily exhaustive or representative of a list of all registrars - that information is stored with ICANN and IANA.

1 0

Re: [gtld-tech] [eppext] RDAP server of the registry
by Hollenbeck, Scott Oct. 9, 2015

Oct. 9, 2015

> -----Original Message----- > From: Greg Aaron [mailto:greg@illumintel.com] > Sent: Wednesday, October 07, 2015 11:27 AM > To: 'Gustavo Lozano'; 'Patrik Wallström'; Hollenbeck, Scott > Cc: gtld-tech(a)icann.org; eppext(a)ietf.org > Subject: RE: [gtld-tech] [eppext] RDAP server of the registry > > Gustavo correctly notes some important things --ICANN has contractual > requirements that tell registries and registrars what data they MUST > deliver > (currently via the WHOIS protocol), and ICANN is now working on how > that > data should be delivered via RDAP. Whatever document is created is > going > to be binding on registries and registrars. As per the 2013 RAA, once > RDAP > spec is mature "ICANN reserves the right to specify alternative formats > and > protocols, and upon such specification, the Registrar will implement > such > alternative specification as soon as reasonably practicable." The new > gTLD > registry agreements contain similar. > > RDAP's supposedly been designed to deliver what ICANN might require of > its > registrars and registries. If so, we are embarking on an exercise in > implementation in the gTLD world, with ICANN as the policy authority. > BCPs > for ccTLDs etc. might be nice, but seem like a distraction from the > immediate task at hand. Thinking about the best way to implement RDAP is no distraction. It will help reduce implementation costs *and* ensure that we deliver the best technical solutions in the long run. Remember, the agreements you mentioned above were written before the RDAP specifications were completed. There are features in RDAP that aren't mentioned in the agreements or the proposed profile. There are ongoing policy efforts in ICANN that *will* have an impact on RDAP implementers. I'm suggesting that we need to take a big picture approach before we're told to implement current WHOIS operational requirements with RDAP as a transport. That just makes RDAP part of the ongoing problems. Here's one example: data privacy. WHOIS can't do it, but RDAP can, and it's not part of the profile. Shouldn't it be part of the discussion? Why shouldn't we think about it before we perpetuate a WHOIS issue that becomes an RDAP issue? > The implementation requirements should certainly be well-thought-out, > should > receive input (and hopefully collegial buy-in) from the parties who > will > have to make it work, and should be clearly documented. As Gustavo > says, > ICANN has process to deliver that. Requiring "community consensus" > about > the contents, as Scott suggested, is a different and higher standard > from > what has been agreed to in the ICANN contracts. I'm not a lawyer, so contracts aren't my area of expertise. I do, however, know something about software engineering and the costs associated with software development. Knowing that the new gTLD RA says this: "Registry Operator shall implement a new standard supporting access to domain name registration data ... if ... its implementation is commercially reasonable in the context of the overall operation of the registry." How does one determine that which is "commercially reasonable"? We know that there are policy development efforts happening in parallel that will produce additional implementation requirements. Requirements that conflict with the profile (changes in data privacy requirements, for example) will increase implementation costs, and "commercially reasonable" becomes a point of contention. The process I've described should help mitigate that risk. It's not a higher standard, it's a method that can be used to help confirm that the "commercially reasonable" requirement has been met. Scott

2 1

RDAP server of the registry
by Gustavo Lozano Oct. 9, 2015

Oct. 9, 2015

Hello, The first version of the ICANN gTLD profile was published days ago, (see: http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html) this document describes basic parameters and objects to be implemented by ICANN-contracted parties. The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date). The gTLD profile support the same functionality with the following mechanism: The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object. Questions for this group: * What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D? Regards, Gustavo Lozano ICANN

7 14

FW: New Version Notification for draft-lozano-rdap-gtld-whois-additional-events-00.txt
by Gustavo Lozano Oct. 4, 2015

Oct. 4, 2015

Hello, [Apologies if you received this email multiple times] I published draft-lozano-rdap-gtld-whois-additional-events-00.txt (see http://www.ietf.org/id/draft-lozano-rdap-gtld-whois-additional-events-00.tx t) that tries to solve open issues 2 and 5 identified in the gTLD RDAP profile (see http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html) The gTLD RDAP profile describes which features, basic parameters and objects will need to be implemented by ICANN-contracted parties in order to support analogous functionality to gTLD Whois service. Your feedback is appreciated. Regards, Gustavo Lozano ICANN On 10/4/15, 11:20, "internet-drafts(a)ietf.org" <internet-drafts(a)ietf.org> wrote: > >A new version of I-D, >draft-lozano-rdap-gtld-whois-additional-events-00.txt >has been successfully submitted by Gustavo Lozano and posted to the >IETF repository. > >Name: draft-lozano-rdap-gtld-whois-additional-events >Revision: 00 >Title: Additional RDAP events to support the gTLD Whois output >Document date: 2015-10-04 >Group: Individual Submission >Pages: 4 >URL: >https://www.ietf.org/internet-drafts/draft-lozano-rdap-gtld-whois-addition >al-events-00.txt >Status: >https://datatracker.ietf.org/doc/draft-lozano-rdap-gtld-whois-additional-e >vents/ >Htmlized: >https://tools.ietf.org/html/draft-lozano-rdap-gtld-whois-additional-events >-00 > > >Abstract: > This document adds two event action types to the IANA RDAP JSON > Values registry, defined in [RFC7483], which are required to map two > fields from the gTLD Whois output into the RDAP response. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat >

1 0

Definition of "% of DNS Service Availability" used in Registrant Survey
by Chris Baker Sept. 28, 2015

Sept. 28, 2015

Hello, I was reading the recent ICANN Releases Phase One Registrant Survey on the Domain Name Landscape and saw mention in the metrics section a "% of DNS Service Availability." I was wondering if there was a definition for this measurement available? Possibly some details about how data is collected where it is collected from? ... etc Please let me know if you have any questions, Thank you for your time, CBaker Reference: "% of DNS Service Availability ( Present SLA is 100% )" Category - Trust in http://newgtlds.icann.org/en/reviews/cct/iag-metrics-final-recs-26sep14-en.…

2 1

About repository identifier
by liangchenguang＠zdns.cn Sept. 15, 2015

Sept. 15, 2015

Dear Sir or Madam, I had to write e-mail to iana,but did not receive a reply.You acknowledge that i send to her acceptance? Mail content: We want to apply for the repository identifier below , among which "zdns" is for registrar and the other 22 IDs are all TLDs. Please check whether they are correct or not. Change Controller ID: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Name: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Thank you. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190

1 0

About repository identifier
by liangchenguang＠zdns.cn Sept. 8, 2015

Sept. 8, 2015

Dear Sir or Madam, We want to apply for the repository identifier below , among which "zdns" is for registrar and the other 22 IDs are all TLDs. Please check whether they are correct or not. Change Controller ID: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Name: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Thank you. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190

1 0

Fw: Re: About repository identifier
by liangchenguang＠zdns.cn Sept. 7, 2015

Sept. 7, 2015

FYI. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190 From: liangchenguang(a)zdns.cn Date: 2015-09-07 17:00 To: Kuhl CC: 高雷; gtld-tech; os_zhangjun Subject: Re: Re: [gtld-tech] About repository identifier Dear Sir or Madam, Sorry, the information in the last email is wrong, this is the update information. Change Controller ID: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Name: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Thank you. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190 From: liangchenguang(a)zdns.cn Date: 2015-09-07 16:28 To: Kuhl CC: 高雷; gtld-tech; os_zhangjun Subject: Re: Re: [gtld-tech] About repository identifier Dear Sir or Madam, Thank you for your response. We want to apply for the repository identifier below , among which "zdns" is for registrar and the other 22 IDs are all TLDs. Please check whether they are correct or not. Change Controller ID: zdns wang top show citic shop ren sohu &#x7f51 &#x5740 &#x7f51 &#x7ad9 &#x7f51 &#x5e97 &#x516b &#x5366 &#x4e2d &#x4fe1 &#x5a31 &#x4e50 &#x5546 &#x6807 &#x62db &#x8058 &#x6211 &#x7231 &#x4f60 &#x65f6 &#x5c1a &#x9910 &#x5385 &#x6148 &#x5584 &#x5546 &#x57ce &#x65b0 &#x95fb &#x96c6 &#x56e2 Change Controller Name: zdns wang top show citic shop ren sohu &#x7f51 &#x5740 &#x7f51 &#x7ad9 &#x7f51 &#x5e97 &#x516b &#x5366 &#x4e2d &#x4fe1 &#x5a31 &#x4e50 &#x5546 &#x6807 &#x62db &#x8058 &#x6211 &#x7231 &#x4f60 &#x65f6 &#x5c1a &#x9910 &#x5385 &#x6148 &#x5584 &#x5546 &#x57ce &#x65b0 &#x95fb &#x96c6 &#x56e2 Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Thank you. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190 From: Rubens Kuhl Date: 2015-09-07 11:33 To: liangchenguang(a)zdns.cn CC: gtld-tech; 高雷 Subject: Re: [gtld-tech] About repository identifier On Sep 6, 2015, at 10:12 PM, liangchenguang(a)zdns.cn wrote: Dear Sir or Madam, A shall be part of the ROID and the identifier shall be registered by IANA. What dose the Controller Email and Reference/Contact Email mean? Change Controller Email and Reference/Contact Email Is the information below right?we want to ues "zdns" as our repository identifier for all our tlds. Although it's not what ICANN prefers, I don't see many options for IDN TLDs... they would prefer the TLD itself due to the possibility a business transaction or a back-end change. Also, RFCs are not totally clear where RoIDs must be unique between domains and contacts, but just in case you could use ZDNHDL and ZDNSDOM, ZDNSHDL and ZDNS etc. Change Controller ID: #x007A #x0064 #x006E #x0073 Change Controlled ID doesn't need to be expressed in this notation, although it could be ZDNS Change Controller Name:#x007A #x0064 #x006E #x0073 Same as above. Reference/Contact ID:#x007A #x0064 #x006E #x0073 This could a person's name represented like Liang_Chen_Guang or a role name Back_End_Registry_Admin Reference/Contact Name:#x007A #x0064 #x006E #x0073 This could Liang Chen Guang, Back End Registry Admin Do we need to provide other information to prove our identity? There is no such thing. Obama could use ZDNS as RoID unique suffix if he registers first... Argentinians might not like the AusRegistry registered AR, but sounds like a good suffix since AusRegistry contains more than 8 letters. Some registries clearly went for random IDs (Q9JYB4C, for instance). Rubens

1 0

About repository identifier
by liangchenguang＠zdns.cn Sept. 7, 2015

Sept. 7, 2015

Dear Sir or Madam, A shall be part of the ROID and the identifier shall be registered by IANA. What dose the Controller Email and Reference/Contact Email mean? Change Controller Email and Reference/Contact Email Is the information below right?we want to ues "zdns" as our repository identifier for all our tlds.Change Controller ID: #x007A #x0064 #x006E #x0073Change Controller Name:#x007A #x0064 #x006E #x0073Reference/Contact ID:#x007A #x0064 #x006E #x0073 Reference/Contact Name:#x007A #x0064 #x006E #x0073 Do we need to provide other information to prove our identity? 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190

3 4

URS and replay attacks
by Rubens Kuhl Sept. 1, 2015

Sept. 1, 2015

@ll, I'm wondering what we have, if any, in resources to prevent URS replay attacks. The threat scenario we've made include access to the "Sent Items" folder of an URS Provider, without access to PGP information. With such access, domains that already received URS-Lock and URS-Suspend commands might be subject to lock or suspension again, even if there is not, at that time, an URS procedure ongoing. That could even happen with a new registrant of that domain. I couldn't find anything in the requirements or URS Provider RFIs that would generate information capable of mitigating this threat... am I missing something ? Rubens

2 2

Verification of the ROID in PDT and upcoming Advisory
by Francisco Arias Aug. 27, 2015

Aug. 27, 2015

Dear Colleagues, As a follow up to the draft updated PDT specifications (http://newgtlds.icann.org/en/announcements-and-media/announcement-2-22jul1 5-en) and the gTLD Registries Operational Workshop held in Buenos Aires, I would like to let you know that ICANN is planning to release a verification of the ROID format as part of Pre-Delegation Testing (PDT). The ROID check would be done as part of both the EPP and Whois tests cases. The verification would check two things: 1) that the ROID is properly formatted as described in RFC 5730, per Specification 6 of the registry agreement; and 2) that the repository identifier used is already registered with IANA (https://www.iana.org/assignments/epp-repository-ids/epp-repository-ids.xht ml). This update will be implemented at the same time as the updates regarding the RDDS (Whois) Advisory. We will implement warnings (no failures) in case of deviations starting on 2 November 2015, and strict enforcement will start on 31 January 2016. Finally, ICANN is planning to release in the next few weeks an advisory at https://www.icann.org/resources/pages/advisories-2012-02-25-en describing the considerations that registries should have when migrating ROIDs. I have attached a draft of the advisory and would appreciate any input you may have by 17 August. Please let me know if you have any questions or comments. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN

2 5

Call for Presentations for TechDay at ICANN Dublin
by Dr Eberhard Lisse Aug. 20, 2015

Aug. 20, 2015

Hi, As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Dublin. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz As we have a very small budget presenters are responsible for their own transport and room and board, though we might be able to assist the most riveting proposal :-)-O As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

Re: [gtld-tech] Draft updated PDT specs and request for feedback
by Kal Feher Aug. 6, 2015

Aug. 6, 2015

My comments on the draft test documents. PDT_TP_Whois: 1. The following line appears to have no matching explicit requirement from the RA or the Whois clarification, it should be removed. In particular the portion relating to the ability to copy and paste the output: “When rendered using a modern web browser the Web whois port 80/443 output MUST contain a section corresponding to the Whois port 43 output that can be copied as a single unit and pasted into a text file.” 2. The AWIP footer should be optional for all reply types. Neither the AWIP policy, nor the Whois clarifications require that the AWIP footer appear under a specific reply type. It is acceptable to include it in all reply types. The text in section 5.5 of the PDT Whois_TP (Appendix) should be updated to reflect the two policy statements by including ‘AWIP footer’ as an optional section above the legal disclaimer for each reply type. 3. The AWIP section description in 5.6.8 PDT_Whois_TP (Appendix) should include both acceptable URLs found in https://www.icann.org/resources/pages/policy-awip-2014-07-02-en. The Whois clarification Advisory references the AWIP announcement and the URL contained therein and does not explicitly override using either EPP status link. PDT_Whois_TC_CLI: WhoisCLI01 - There is no Char Encoding declaration section in the current pdtwhois.xml file or matched schema files. I’m assuming this variable doesn’t refer to the xml header. Should a new input file and schema have been provided with the drafts test cases? If so, please send that to the list for review as well. PDT_Whois_TC_Web: WhoisWeb01 – There is no explicit or implied requirement for HTTPS for web based whois in the Registry Agreement or the clarifications announcement. The lack of HTTPS should not be cause for a warning. The previous PDT_Whois_TC_Web document (E) had HTTPS as optional and I’m not aware of any recent approved policy which overrides this. Perhaps the pdtwhois.xml file should include an element stating whether HTTPS is supported or not. If it is, then the criteria for PASS, WARN and FAIL can remain unchanged. If HTTPS is explicitly not supported, then HTTPS testing should be limited to confirming that it is in fact not available. -- Kal Feher -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias Sent: Friday, 24 July 2015 7:24 PM To: gtld-tech(a)icann.org Cc: Russ Weinstein Subject: [gtld-tech] Draft updated PDT specs and request for feedback This message contains a digitally signed email which can be read by opening the attachment.

3 5

Re: [gtld-tech] ICANN CRL expired and not updated yet
by Kal Feher July 31, 2015

July 31, 2015

Francisco, Can you please provide the length of the outage period and the symptoms observed by users as currently understood? Clearly stating the known facts would be useful for all those who rely on the service and who need to now identify invalid submission failures. -- Kal Feher -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias Sent: Tuesday, 28 July 2015 11:39 AM To: David Krizanic; gtld-tech(a)icann.org Subject: Re: [gtld-tech] ICANN CRL expired and not updated yet This message contains a digitally signed email which can be read by opening the attachment.

3 3

ICANN CRL expired and not updated yet
by David Krizanic July 28, 2015

July 28, 2015

All, We've had registrars come to us with complaints of inability to submit sunrise applications and it turns out that the ICANN CRL (http://crl.icann.org/tmch.crl) has expired, since there's been a number of seemingly unrelated issues over the past months our sunrises have been suffering. We are now waiting for an update while validating any SMD is failing. Best, David DAVID KRIZANIC Famous Four Media - Head of Technology 2nd Floor, Leisure Island Business Centre Ocean Village, Gibraltar Phone: +350 216 50006 Email: dkrizanic(a)famousfourmedia.com

3 4

Re: [gtld-tech] ICANN CRL expired and not updated yet
by Francisco Arias July 28, 2015

July 28, 2015

Hi David, We are looking into this and should have an update shortly. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN On 7/27/15, 8:29 AM, "David Krizanic" <dkrizanic(a)famousfourmedia.com> wrote: >All, > >We've had registrars come to us with complaints of inability to submit >sunrise applications and it turns out that the ICANN CRL >(http://crl.icann.org/tmch.crl) has expired, since there's been a number >of seemingly unrelated issues over the past months our sunrises have been >suffering. We are now waiting for an update while validating any SMD is >failing. > >Best, >David > >DAVID KRIZANIC >Famous Four Media - Head of Technology >2nd Floor, Leisure Island Business Centre Ocean Village, Gibraltar >Phone: +350 216 50006 >Email: dkrizanic(a)famousfourmedia.com > >

1 1

Draft updated PDT specs and request for feedback
by Francisco Arias July 24, 2015

July 24, 2015

Please see below an announcement regarding draft updated PDT specifications and request for feedback. Regards, -- Francisco. On 7/23/15, 8:48 PM, "Russ Weinstein" <russ.weinstein(a)icann.org> wrote: >--- > >Colleagues, > >We have just released a draft of the Pre-Delegation Testing (PDT) >specifications for the Whois Testing, incorporating the recently >published clarification Advisory >(https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04 >-27-en). We would like to use this mailing list to solicit feedback >regarding the specifications between now and August 14. At which point >we will close the feedback period, make any necessary changes to the test >specifications and begin the software development cycle. We plan to >implement testing to the new specifications in early November 2015. All >testing done before the enforcement date of the Advisory (31 January 2015) >will treat any conformance with the Advisory as a "warning condition” and >will not prevent the registry from passing PDT. Any conformance after the >enforcement date will be treated as a "fail condition" and the registry >will not pass PDT until they meet all requirements. > > >Please see the announcement published on 23 July for the release of the >draft Whois specifications: >http://newgtlds.icann.org/en/announcements-and-media/announcement-2-22jul1 >5-en where you will find a link to the documents. Please review the >README file included as it provides more details about the timeline >toward implementation. > >Your feedback and participation is appreciated. Thanks > >__ > >Russ

1 0

FW: IETF lager working group
by Francisco Arias July 20, 2015

July 20, 2015

FYI On 7/18/15, 8:31 AM, "Marc Blanchet" <marc.blanchet(a)viagenie.ca<mailto:marc.blanchet@viagenie.ca>> wrote: Hello, a new IETF working group has been formed recently, named: lager (Label Generation Rules). Charter listed below FYI. This work has impact to any software that checks if domains (especially tlds and 2nd level) are valid for a registry, for various use cases: registration, domain check, etc… Valid not in the IDNA2008 sense, but the « file format » defines the restricted set of code points and related rules (variants for example) accepted by a registry. since the wg was formed after the deadline to submit meeting requests for Prague, we do not have a formal meeting session. But Scott and I, co-chairs, would like to arrange some informal talks (Scott company will pay the lager…) to start the work. Could anyone interested in attending that informal meeting send me+scott an email so we can doodle a meeting time during the Prague IETF week. Regards, Marc. Lager Charter ( http://datatracker.ietf.org/wg/lager/charter/) Domain registries, particularly those implementing IDNA (RFC 5890 et.al), usually maintain a set of criteria (or "ruleset") that governs permissible labels allowed for registration, such as [IANAIDNTABLES]. These rulesets are commonly a mixture of eligible code points along with contextual criteria that must be met concerning the positioning of certain code points. Some registries also specify rules regarding variant labels and how they are to be handled. Domain registries commonly need to share these rules, but there is no interoperable format that can be used that can support many common use cases. This group seeks to produce such a format, which will enable re-use and sharing of existing rulesets, and simpler implementation of new rulesets in registries. A comprehensive format specification has been developed, named Label Generation Rules, primarily to support the rules to be used for the DNS Root Zone [Davies]. This group will use this specification as a starting point to develop a common XML language that provides a superset of functionality of current specifications [RFC 3743, RFC 4290, et.al], along with other known use cases. This single format is expected to supersede existing formats, and form the basis for future rulesets used at different levels of the DNS hierarchy. Work items: - Standard Track Specification of the Label Generation Rules References: [Davies] https://datatracker.ietf.org/doc/draft-davies-idntables/ [IANAIDNTABLES] https://www.iana.org/domains/idn-tables

1 0

Publishing of the Change Poll EPP Extension IETF Draft
by Gould, James July 7, 2015

July 7, 2015

The first draft of the Change Poll EPP Extension ( http://tools.ietf.org/html/draft-gould-change-poll-00 ) has been submitted to the IETF. I co-authored this draft with Trung Tran from Neustar to provide a mechanism within EPP to notify clients of any server-side change, including but not limited to regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-data of what, when, who, and why. We would like this draft to be included in a re-charting of the EPPEXT Working Group. Please review the draft and provide any feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

2 2

Re: [gtld-tech] TMCH - Service not available
by Michele Neylon - Blacknight July 1, 2015

July 1, 2015

Is this impacting the EPP service? Or is it just the web service? -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social Random Stuff: http://www.michele.irish/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 On 29/06/2015 08:34, "gtld-tech-bounces(a)icann.org on behalf of Alexander Mayrhofer" <gtld-tech-bounces(a)icann.org on behalf of alexander.mayrhofer(a)nic.at> wrote: >Guys, > >while it seems that the certificate configuration looks sane now, the whole TMCH service (again) seems to be down again: > >https://ry.marksdb.org/ > >"This service of the Trademark Clearinghouse Database (TMDB) web client is currently not available. >Please try again later. Our apologies for the inconvenience." > >Please. Fix. This. > >Alex >

6 6

TMCH - Service not available
by Alexander Mayrhofer June 29, 2015

June 29, 2015

Guys, while it seems that the certificate configuration looks sane now, the whole TMCH service (again) seems to be down again: https://ry.marksdb.org/ "This service of the Trademark Clearinghouse Database (TMDB) web client is currently not available. Please try again later. Our apologies for the inconvenience." Please. Fix. This. Alex

1 0

Fw: TMCH: HIGHLY Insecure SSL config / certificates.
by Luc Van Steen1 June 26, 2015

June 26, 2015

All, We are currently working on this issue and you will be informed once the changes have been performed. Regards, Luc Van Steen IT Specialist Phone: 32-2-339-8377 | Mobile: 32-486-259819 E-mail: luc.van.steen(a)be.ibm.com International Business Machines of Belgium sprl / bvba Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336 RPM Bruxelles / RPR Brussel ----- Forwarded by Wim Fabri/Belgium/IBM on 26/06/2015 10:28 ----- From: Alexander Mayrhofer <alexander.mayrhofer(a)nic.at> To: "gtld-tech(a)icann.org" <gtld-tech(a)icann.org> Date: 26/06/2015 10:14 Subject: [gtld-tech] TMCH: HIGHLY Insecure SSL config / certificates. Sent by: gtld-tech-bounces(a)icann.org All, it seems like the TMCH has rolled out a new certificate on the various marksdb.org interfaces. Besides the fact that the certificate now uses an intermediate cert that was not delivered with the chain (and hence made our TLS connect fail initially), we took a look at the general TLS configuration of the interfaces, and it seems that the TLS configuration is HIGHLY insecure at the moment: https://www.ssllabs.com/ssltest/analyze.html?d=ry.marksdb.org (see "Protocol Details") Could someone from the TMCH indicate whether they are working on fixing these serious issues? Thanks, Alex Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above: International Business Machines of Belgium sprl / bvba Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336 RPM Bruxelles / RPR Brussel

1 0

TMCH: HIGHLY Insecure SSL config / certificates.
by Alexander Mayrhofer June 26, 2015

June 26, 2015

All, it seems like the TMCH has rolled out a new certificate on the various marksdb.org interfaces. Besides the fact that the certificate now uses an intermediate cert that was not delivered with the chain (and hence made our TLS connect fail initially), we took a look at the general TLS configuration of the interfaces, and it seems that the TLS configuration is HIGHLY insecure at the moment: https://www.ssllabs.com/ssltest/analyze.html?d=ry.marksdb.org (see "Protocol Details") Could someone from the TMCH indicate whether they are working on fixing these serious issues? Thanks, Alex

4 4

Almost Final Agenda for TechDay at ICANN53 Buenos Aires
by Dr Eberhard Lisse June 11, 2015

June 11, 2015

Please find enclosed the almost final agenda for the coming TechDay. Unless we get a short notice cancellation the topics are final, but the order and time slots my change somewhat if scheduling conflicts need to be resolved. Please take note again, that we are going to have a PGP/GPG Key Signing Event at TechDay. We have secured additional meeting space for short ceremonies for individuals who can't make it to the main ceremony during lunchtime of Tuesday, Wednesday and Thursday. A short introduction is on: http://en.wikipedia.org/wiki/Key_signing_party We have created a keyring on the website created to assist with such events http://biglumber.com/x/web?keyring=2592 If you wish to have your key signed, you you *MUST* paste an ASCII-armored file containing the key(s) you wish to add to the keyring into the provided text area. In my case I first looked at what keys I actually have: gpg --list-keys el(a)lisse.NA which showed: pub 1024R/A6490CB9 1995-09-07 [revoked: 2015-02-13] [...] pub 4096R/79453FAB 2015-02-08 uid Dr Eberhard W Lisse <el(a)lisse.na> uid Dr Eberhard W Lisse <doc(a)lisse.na> uid [jpeg image of size 14847] [...] and then used gpg --export -a 79453FAB to generate the ASCII-armored file (of the non-revoked key) which I uploaded and is now visible on the site, and which is used to sign this email. greetings, el

1 0

PGP/GPG Key Signing Ceremony at TechDay in Buenos Aires
by Dr Eberhard W Lisse June 2, 2015

June 2, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Colleagues, please take note again, that we are going to have a Key Signing Ceremony at TechDay in Buenos Aires (ie on Monday). We have secured additional meeting space for short ceremonies for individuals who can't make it to the main ceremony (see at the end of this mail). A short introduction is on: http://en.wikipedia.org/wiki/Key_signing_party We have created a keyring on the website created to assist with such events http://biglumber.com/x/web?keyring=2592 If you wish to have your key signed, you you *MUST* paste an ASCII-armored file containing the key(s) you wish to add to the keyring into the provided text area. In my case I first looked at what keys I actually have: gpg --list-keys el(a)lisse.NA which showed: pub 1024R/A6490CB9 1995-09-07 [revoked: 2015-02-13] [...] pub 4096R/79453FAB 2015-02-08 uid Dr Eberhard W Lisse <el(a)lisse.na> uid Dr Eberhard W Lisse <doc(a)lisse.na> uid [jpeg image of size 14847] [...] and then used gpg --export -a 79453FAB to generate the ASCII-armored file (of the non-revoked key) which I uploaded and is now visible on the site, and which is used to sign this email. greetings, el On 2015-06-02 07:35 , Kristina Nordstrom wrote: [...] > Tuesday 23 June 12:45-14:00 ART > > Informal Tech Working Group Meeting (CLOSED); Retiro A > > > Wednesday 24 June 13:00-14:00 ART > > Informal Tech Working Group Meeting (CLOSED); Retiro A > > > Thursday 25 June 12:00-13:00 ART > > Informal Tech Working Group Meeting (CLOSED); Retiro C [...] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIVAwUBVW1wyJcFHaN5RT+rAQIhrRAArFsFbeeOJGA0jHIMDZbEdP8Q7z3w8vKf pDCIHPih0jg9XMSGf3Awb6y6rMM1SosvV/VD8YehJ3II1azkPM43ApEyqSIDztIX k6G1fQtZNNA6Z8PNZ9vgvXYz+wvIxV8BviH/FZKWc3uduRLhPxR8nhYyZlncyuKj NNGZQQvHytFdxn/LUFmIZp2lvML63A+S6iTGfZ9AK5b7U8BrPuSzfJpbF4iqO/oA WKV77jF+/ceezZbweR1t47Vlm11Rp3t6nEzQwbItyzk3xKfM+v3CqeHMDyY0u2q3 A+DC7rUPojXzRcYRfJDZ7U0Z4zc/6bXsoAUIK2R/5QdJ9eZCd5InZG0N5YjYJTMu eW6U2ga4eK1YgXP73xDNpwIXNPEYpP+0qO4y7gmb8jjEyyqnhWGLuJqkhv4ndyCe ABRbJY6zwcac0hlQWUhQ7b3vcyvZmdNLxqfLclBKOZZVYKKQrF0FYB+3W2ctcM/n Ewo64+8o0YswHinLplVGstFeONSRgOdz3aKmrnga99fRRDe+Vk2rU0zxg3bPnINW L1BDlGsrBsOEJ8OyzziPQzI/w8hFtr6bPpfD9D1m0V58uqvh0AMXhRYa2vDzoBwX GdqRzu2oIPPGvT0M5meqiV6oDBuXN5WMsGjApWmju4MybGJZzS4U16OIq4HHTWGY PffRaUHbAYw= =5teR -----END PGP SIGNATURE-----

1 0

Re: [gtld-tech] [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft
by Rubens Kuhl May 31, 2015

May 31, 2015

James et al, Has the use case of DNS publishing been considered for the changepoll extension ? Some registries defer publication of a domain to the registry zone until DNS servers respond correctly (authoritative, DNSKEY matches DS etc.), and a poll message could signal that to the sponsoring client. I couldn't find an appropriate operation in changepoll-02... what are your and the group's thoughts on this ? Rubens > Em 30/01/2015, à(s) 11:53:000, Gould, James <JGould(a)verisign.com> escreveu: > > Ulrich, > > Thank you for the review of the draft. My feedback is embedded below. > > I received private feedback to add an optional caseId element to help capture the UDRP, URS, or other case identifier for the change. The optional caseId element was added with an enumerated “type” attribute, with the enumerated values of “udrp”, “urs”, and “custom”, and with an optional “name” attribute for the “custom” type. Are there any additional case types that should be included in the enumerated list? You can see the latest updates of the draft using the GitHub project https://github.com/james-f-gould/EPP-Change-Poll.git <https://github.com/james-f-gould/EPP-Change-Poll.git>. > > — > > JG > > > <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png> > > James Gould > Distinguished Engineer > jgould(a)Verisign.com <x-msg://23/jgould@Verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com <http://verisigninc.com/> > On Jan 30, 2015, at 4:08 AM, Ulrich Wisser <ulrich(a)wisser.se <mailto:ulrich@wisser.se>> wrote: > >> Hi James and Trung! >> >> You two did a nice job on the extension. >> >> I would prefer the transform command instead of the info response. That would eliminate the need for before/after indicator. > > You mean you want to see the full input transform command in the poll message? Most of the server-side operations don’t go through EPP, so it would be a challenge to attempt to present the input prior to executing the operation using an EPP transform command. Another issue with using a transform command is representing the server-side logic that is not reflected in the input parameters like the setting of the expiration date. The client can see the end result of the operation without having to replicate the transform operation logic, along with the meta-data about the operation using the info response. > > One question for the list is the value in making the before image of the object available? The after image is required, but the thought is that the before image may be desired. > >> >> I have some problems with the operators >> >> - Why is autoRenew a special operation instead of operation renew with op="auto”? > > I agree that both are associated with renewing the domain; although I view them as separate first class operations with different characteristics (What drives the operation, how does the operation function, and what is the applicable grace period for the operation). > > >> - What is the difference between delete and delete op="purge”? > > Good question. Purge is associated with physically removing the object from the database where the delete could start an RGP lifecycle flow. An immediate delete (e.g. delete within the add grace period) is reflected by a “delete” with the op=“purge”; otherwise it would be just “delete”. > >> - Why autoPurge / autoDelete? > > Another good question. What if for some registries the domain is deleted instead of auto renewed at expiry? That would match the use of the “autoDelete” operation. Now, the “autoDelete” could include the purging of the object which would be reflected by setting op=“purge”. The autoPurge operation is the server batch that physically purges the object (domain) at the end of the pendingDelete period. In this case the domain has been deleted, put through the RGP lifecycle flow, and is being purged from the database. We wanted to handle both types of registries (auto renew and auto delete) as well as be able to identify the event when the object is purged from the database. I hope this makes sense. > >> >> Kind regards from Stockholm >> >> Ulrich >> >> >> >> 2015-01-20 14:49 GMT+01:00 Gould, James <JGould(a)verisign.com <mailto:JGould@verisign.com>>: >> The first draft of the Change Poll EPP Extension ( http://tools.ietf.org/html/draft-gould-change-poll-00 <http://tools.ietf.org/html/draft-gould-change-poll-00> ) has been submitted to the IETF. I co-authored this draft with Trung Tran from Neustar to provide a mechanism within EPP to notify clients of any server-side change, including but not limited to regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-data of what, when, who, and why. We would like this draft to be included in a re-charting of the EPPEXT Working Group. >> >> Please review the draft and provide any feedback. >> >> Thanks, >> >> — >> >> JG >> >> >> <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png> >> >> James Gould >> Distinguished Engineer >> jgould(a)Verisign.com <http://jgould@verisign.com/> >> >> 703-948-3271 <tel:703-948-3271> >> 12061 Bluemont Way >> Reston, VA 20190 >> >> VerisignInc.com <http://verisigninc.com/> >> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.” >> >> >> _______________________________________________ >> provreg mailing list >> provreg(a)ietf.org <mailto:provreg@ietf.org> >> https://www.ietf.org/mailman/listinfo/provreg <https://www.ietf.org/mailman/listinfo/provreg> >> >> >> _______________________________________________ >> EppExt mailing list >> EppExt(a)ietf.org <mailto:EppExt@ietf.org> >> https://www.ietf.org/mailman/listinfo/eppext > > _______________________________________________ > 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>

3 4

PGP Signing Party at Tech Day Buenos Aires
by Dr Eberhard W Lisse May 24, 2015

May 24, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, we would like to do a PGP Key Signing Party as part of Tech Day in Buenos Aires. A short introduction is on: http://en.wikipedia.org/wiki/Key_signing_party We have created a keyring on the website created to assist with such events http://biglumber.com/x/web?keyring=2592 If you wish to have your key signed, you you must paste an ASCII-armored file containing the key(s) you wish to add to the keyring into the provided text area. In my case I first looked at what keys I actually have: gpg --list-keys el(a)lisse.NA which showed: pub 1024R/A6490CB9 1995-09-07 [revoked: 2015-02-13] [...] pub 4096R/79453FAB 2015-02-08 uid Dr Eberhard W Lisse <el(a)lisse.na> uid Dr Eberhard W Lisse <doc(a)lisse.na> uid [jpeg image of size 14847] [...] and then used gpg --export -a 79453FAB to generate the ASCII-armored file (of the non-revoked key) which is now visible on the site, and which is used to sign this email. greetings, el -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIVAwUBVWI7ApcFHaN5RT+rAQKKzw//dZOVyxvXNBw/44yFja3dNKekx7UsDMz/ /0bOALGmzCML6/AVJNmUsCBKU3xC2j+rRWtvwYIvo5XwFpxvyCVxAn7tKBSQTxrC AojTqoY59D3m5e1MrN6MrpOKSKg5rBVgIeM/+sS+8Sp+RVzHE9NZ6HQfQXjB1/D8 Bqn+yws1YRoM6Q2YrIuTm9TrkjqqydPuVH6ypPlQkjrL1PaD7SWxQN+DxbvrGKFc lwFguOqYTNMziJYxQDlvV1tXzC3EZ0ZVQ2zrlRSc7UtWk+f+ILu4yYJi3Dpad8+X io2MLG2Q5euLgQV2iaIwgbnqAbdFnxmV6RtdOrOePRMP8aNfwSqhsGouxpAgUCxj oe8AA1ynCKydbeAQoJ6ZGV4IkASQ0WNNda7DaQy1V4TmZDqjHeVsJqvsuz+3+hGq lqkevI2Be+8axsjvpZEb3ibhYuvaQuLIOpI6odTODc0M/8QpjPjlJKQkhiSO/ahn fv3UwhWwklpGPdvlD91XehBhL8I2SwtM0WmRpIdHGlHqTJKPd28wdxXZFyTisrri bqDaBr1iU4smXog9ck3QCUfA14oYOJZHBTWd/zeZCS7UdXw/1FjZBPjx4Ga72gp9 bVc857mhmQVTMNgxfRPSpkMPxlqZagfVgvBHvvNeF0QhjUiSnu/nmqdjErgBhjcv HyUCo8HlvOM= =tOqu -----END PGP SIGNATURE-----

1 0

TMDB down?
by Alexander Mayrhofer May 18, 2015

May 18, 2015

Hi, we're currently experiencing errors when fetching files from the TMCH. Additionally, our registrars are reporting issues with fetching Claims information. Have i missed a maintenance announcement, or is this an unplanned outage? When we're trying to fetch the DNL from https://ry.marksdb.org/dnl/dnl-latest.csv , we do get a HTTP 200 OK response, but the file we receive contains: <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>TMDB - Trademark-Database</title> </head> <body> <h1>This service of the Trademark Clearinghouse Database (TMDB) web client is currently not available.</h1> Please try again later. Our apologies for the inconvenience. </body> </html> Same for the SMD revocation list. Since we do not have a production registrar TMCH account, i cannot verify the issue for the claims interface. Are other registries experiencing similar issues? Has anybody received any notification from either ICANN or the TMCH? Thanks, Alex Mayrhofer TLDBOX

3 3

Re: [gtld-tech] Whois Advisory - upcoming publication
by Francisco Arias April 27, 2015

April 27, 2015

Colleagues, Just to let you know that the final Whois advisory has been published at https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04-2…, the effective date is 31 January 2016. As explained in the announcement (https://www.icann.org/news/announcement-2015-04-27-en) contracted parties will receive formal notice within the next two weeks. Regards, -- Francisco. On 4/14/15, 1:01 PM, "Francisco Arias" <francisco.arias(a)icann.org<mailto:francisco.arias@icann.org>> wrote: Dear RrSG and RySG members and colleagues, Attached please find the draft Whois advisory that ICANN intends to publish as final by 27-Apr-2015 with an effective implementation date of at least, 6 months after publication (final effective date TBD), providing contracted parties ample time to implement any necessary changes. As you may know we have had several interactions between ICANN and the community to define the contents of the Advisory. We believe this Advisory incorporates the input received and is ready for publication. We wanted to give a heads up to the contracted parties and the community in general of the upcoming publication. Thank you again for your time and your constructive inputs. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN

1 0

Call for Presentations for TechDay at ICANN Buenos Aires
by Dr Eberhard Lisse April 21, 2015

April 21, 2015

Hi, As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Buenos Aires. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz As we have a very small budget presenters are responsible for their own transport and room and board, though we might be able to assist the most riveting proposal :-)-O As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O greetings, el

1 0

Whois Advisory - upcoming publication
by Francisco Arias April 14, 2015

April 14, 2015

Dear RrSG and RySG members and colleagues, Attached please find the draft Whois advisory that ICANN intends to publish as final by 27-Apr-2015 with an effective implementation date of at least, 6 months after publication (final effective date TBD), providing contracted parties ample time to implement any necessary changes. As you may know we have had several interactions between ICANN and the community to define the contents of the Advisory. We believe this Advisory incorporates the input received and is ready for publication. We wanted to give a heads up to the contracted parties and the community in general of the upcoming publication. Thank you again for your time and your constructive inputs. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN

1 0

draft-gould-idn-table-02 Posted
by Gould, James April 2, 2015

April 2, 2015

The third draft of draft-gould-idn-table ( draft-gould-idn-table-02 ) was posted to the IETF to address the feedback received from the Registration Operations Workshop (ROW), held on March 22, prior to IETF-92. The following is the draft information: URL: http://www.ietf.org/internet-drafts/draft-gould-idn-table-02.txt Status: https://datatracker.ietf.org/doc/draft-gould-idn-table/ Htmlized: http://tools.ietf.org/html/draft-gould-idn-table-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-gould-idn-table-02 The following is a description of the changes from draft-gould-idn-table-01 to draft-gould-idn-table-02: 1. Removed support for returning the idnTable:codePoint and idnTable:codeRange elements in the table info response based on the feedback at the Registration Operations Workshop (ROW), held on March 22, 2015, prior to IETF-92. 2. Fixed info command samples that referenced the <check> element instead of the <info> element. Please review and provide your feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0

draft-ietf-eppext-launchphase-05 Posted
by Gould, James March 31, 2015

March 31, 2015

All, The sixth draft of draft-ietf-eppext-launchphase (draft-ietf-eppext-launchphase-05) was posted to the IETF to address the items discussed at the EPPEXT WG meeting to start the Working Group Last Call. The following is the draft information: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-launchphase/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-launchphase-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-launchphase-05 The following is a description of the changes from draft-ietf-eppext-launchphase-04 to draft-ietf-eppext-launchphase-05: 1. Added a missing comma to the description of the <launch:phase> element, based on feedback from Keith Gaughan on the eppext mailing list. 2. Added the SIDN implementation status information. 3. Fixed a few indentation issues in the samples. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.” “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0

Publishing of the IDN Table EPP Mapping IETF Draft
by Gould, James March 13, 2015

March 13, 2015

The first draft of the IDN Table EPP Mapping has been submitted to the IETF. I co-authored this draft with Francisco Obispo and Luis Muñoz from Uniregistry to provide a mechanism for getting IDN Table information for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension ( draft-ietf-eppext-idnmap ). We would like this draft to be included in a re-charting of the EPPEXT Working Group. The draft information is provided below. URL: http://www.ietf.org/internet-drafts/draft-gould-idn-table-00.txt Status: https://datatracker.ietf.org/doc/draft-gould-idn-table/ Htmlized: http://tools.ietf.org/html/draft-gould-idn-table-00 Please review the draft and provide any feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

2 3

draft-ietf-eppext-tmch-smd-01 Posted
by Gustavo Lozano March 3, 2015

March 3, 2015

Hello colleagues, Version 01 of draft-ietf-eppext-tmch-smd was posted to the Internet-Draft repository. The draft is ready for Working Group Last Call (EPPEXT WG). The draft can be found here: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-01 Your feedback is appreciated, please use the eppext mailing list. Regards, Gustavo

1 0

draft-ietf-eppext-launchphase-04 Posted
by Gould, James Feb. 27, 2015

Feb. 27, 2015

All, The fifth draft of draft-ietf-eppext-launchphase (draft-ietf-eppext-launchphase-04) was posted to the IETF to include the EPP Extension Registry section under the IANA Considerations. This draft is ready for Working Group Last Call by the EPPEXT Working Group. I support draft-ietf-eppext-tmch-smd moving to Working Group Last Call as well. The following is the draft information: URL: https://tools.ietf.org/id/draft-ietf-eppext-launchphase-04.txt<http://www.ietf.org/internet-drafts/draft-ietf-eppext-launchphase-03.txt> Status: https://datatracker.ietf.org/doc/draft-ietf-eppext-launchphase/ Htmlized: https://tools.ietf.org/html/draft-ietf-eppext-launchphase-04<http://tools.ietf.org/html/draft-ietf-eppext-launchphase-03> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-launchphase-04<http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-launchphase-03> The following is a description of the changes from draft-ietf-eppext-launchphase-03 to draft-ietf-eppext-launchphase-04: 1. Amended XML Namespace section of IANA Considerations, added EPP Extension Registry section. Please review draft-ietf-eppext-launchphase-04 and post any issues to the eppext mailing list. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.” “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0

Question on contact:chg / contact:postalInfo / contact:addr
by Volker Janzen Notify Feb. 25, 2015

Feb. 25, 2015

Hi all, I've a question regarding contact:addr inside of a contact:postalInfo block when using contact:chg. E.g. this XML snippet from RFC 5733 (excerpt only): C: <contact:chg> C: <contact:postalInfo type="int"> C: <contact:org/> C: <contact:addr> C: <contact:street>124 Example Dr.</contact:street> C: <contact:street>Suite 200</contact:street> C: <contact:city>Dulles</contact:city> C: <contact:sp>VA</contact:sp> C: <contact:pc>20166-6503</contact:pc> C: <contact:cc>US</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: </contact:chg> contact:street may occur zero to three times. Is it intended that a single contact:street element should replace all existing contact:street elements or only the first contact:street element of the contact object? Volker Janzen Team Entwicklung -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel: +49 941 59559-0 Fax: +49 941 59579-050 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Geschäftsführer/CEO: Thomas Mörz Amtsgericht Regensburg, HRB 7142 GPG-Key: 0x186C5F77 GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77

4 3

Publishing of the Change Poll EPP Extension 01 IETF Draft
by Gould, James Feb. 23, 2015

Feb. 23, 2015

The second draft of the Change Poll EPP Extension ( https://tools.ietf.org/html/draft-gould-change-poll-01 ) has been published to the IETF. This draft includes the following change: 1. Added an optional caseId element that defines the case identifier from UDRP, URS, or custom case, based on feedback from Michael Holloway. Please review the draft and provide any feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0

draft-lozano-tmch-func-spec and QLP addendum
by Rik Ribbers Feb. 10, 2015

Feb. 10, 2015

Hello, I've got a question concerning the QLP addendum in relation to the IETF TMCH functional specification draft (http://tools.ietf.org/id/draft-lozano-tmch-func-spec-09.txt ) In section "5.4.1. Domain Registration" of the IEFT draft a decision table is provided the services a registry must provide for the QLP allocation scenarios. This table suggests that a QLP registration during sunrise must be validated against the DNL list and the SURL list. However in the QLP addendum it is only mentioned that a QLP registration during sunrise must be validated against the SURL list. I assume that the addendum is correct, but is that a correct assumption? Kind regards, Rik Ribbers

2 2

TechDay ICANN 52 Final Agenda
by Dr Eberhard W Lisse Feb. 7, 2015

Feb. 7, 2015

Kristina, please find enclosed the agenda, as promised. All, please distribute widely. We are particularly grateful for ICANN IT staff to be available for an Adobe Connect Hands-On training. Anyone who has telephone issues when participating in conferences using Adobe Connect might benefit from learning how to use Adobe Connect's Audio facilities (two-ways). greetings, el

1 0

Adobe Connect Hands On Session at ICANN Singapore TechDay
by Dr Eberhard W Lisse Feb. 3, 2015

Feb. 3, 2015

Hi, we shall have us an Adobe Connect Hands on session over lunch (13:00) on Monday at TechDay ICANN Singapore in the Olivia Room thanks to ICANN IT staff. In particular would I like to make the feature known that one can interact with the conference call bridge by way of "connecting audio". This is helpful for those who find themselves in a situation of poor telephone reachability but with acceptable Internet connectivity as a fail-safe. I would appreciate if you could circulate this to lists and individuals who you think may benefit of this session. greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

Re: [gtld-tech] Upcoming publication of updated Whois advisory
by Francisco Arias Feb. 2, 2015

Feb. 2, 2015

Colleagues, The meeting will be held on 11 February from 16:15 to 17:30 UTC+8 (Singapore time) in Moor room during the ICANN meeting in Singapore. Remote participation will be available as follows. https://icann.adobeconnect.com/whois_clar_icann52/ Phone access numbers can be found at https://mtginfo.pgi.com/globalcallmanagement.asp?bwebid=9820041&cid=da6de6b… or in the attached PDF. Access code: 1619764184. Regards, -- Francisco. On 1/28/15, 11:47 PM, "Alexander Mayrhofer" <alexander.mayrhofer(a)nic.at<mailto:alexander.mayrhofer@nic.at>> wrote: Cyrus, Thank you for that information. Can you elaborate in which session the advisory will be discussed during the ICANN meeting? I’d highly interested in joining that. thanks, Alex Von: gtld-tech-bounces(a)icann.org<mailto:gtld-tech-bounces@icann.org> [mailto:gtld-tech-bounces@icann.org] Im Auftrag von Cyrus Namazi Gesendet: Donnerstag, 29. Jänner 2015 02:07 An: gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> Cc: Krista Papac; Mike Zupke; Fabien Betremieux Betreff: Re: [gtld-tech] Upcoming publication of updated Whois advisory Dear all; Following further correspondence and additional feedback from some of the stakeholders, we will hold off on publishing this advisory until after our face-to-face meeting at ICANN 52 in Singapore. Cheers, Cyrus Namazi ICANN From: Cyrus Namazi <cyrus.namazi(a)icann.org<mailto:cyrus.namazi@icann.org>> Date: Friday, January 23, 2015 at 12:38 PM To: <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Cc: Krista Papac <krista.papac(a)icann.org<mailto:krista.papac@icann.org>>, Mike Zupke <Mike.Zupke(a)icann.org<mailto:Mike.Zupke@icann.org>>, Francisco Arias <francisco.arias(a)icann.org<mailto:francisco.arias@icann.org>>, Fabien Betremieux <fabien.betremieux(a)icann.org<mailto:fabien.betremieux@icann.org>> Subject: Upcoming publication of updated Whois advisory Dear RySG and RrSG members and colleagues, Attached please find the Whois advisory scorecard identifying those issues raised during ICANN’s numerous consultations with various interested parties over the course of the previous several months. The scorecard contains (among other things) a description of the issue raised and ICANN’s response. I thank the group members for their valuable contributions throughout these discussions. We have updated the draft advisory on those issues where there was room for interpretation. There are a small number of issues (three) that we think the Whois specifications do not allow for the changes some of you have proposed (rows 3, 8, and 15 of the attached scorecard). Consequently, there are only three issues in which we found no option but to maintain the current Whois advisory language. ICANN intends to publish a final advisory by the end of January with an implementation date of 31 July 2015, providing contracted parties ample time to implement any necessary changes. Thank you again for your time and your constructive inputs. Please let us know should you have any further questions or comments. Cheers, Cyrus Namazi Vice President | Domain Name Services | Global Domains Division 801 17th St NW, Suite 400 | Washington, DC 20006 USA +1.202.249.7543 Office | +1.408.421.6894 Mobile | cyrus.namazi(a)icann.org<mailto:cyrus.namazi@icann.org> www.icann.org<http://www.icann.org>

1 1

TLD Name Server Software/Appliances
by Robert Smith Jan. 31, 2015

Jan. 31, 2015

Good evening, I'm trying to find/compile a list of name server software that the primary TLD servers use. I've found the root servers use BIND, with a few using NSD; is this about the same usage across TLD servers, as well? Or perhaps some TLDs use particular appliances instead? Thank you, - RS

4 3

draft-ietf-eppext-launchphase-03 Posted
by Gould, James Jan. 29, 2015

Jan. 29, 2015

All, The fourth draft of draft-ietf-eppext-launchphase (draft-ietf-eppext-launchphase-03) was posted to the IETF as what should be ready for Working Group Last Call by the EPPEXT Working Group. There is a dependency to draft-ietf-eppext-tmch-smd, so the hope is that draft-ietf-eppext-tmch-smd can be reposted for Working Group Last Call as well. The following is the draft information: URL: http://www.ietf.org/internet-drafts/draft-ietf-eppext-launchphase-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-eppext-launchphase/ Htmlized: http://tools.ietf.org/html/draft-ietf-eppext-launchphase-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-launchphase-03 The following is a description of the changes from draft-ietf-eppext-launchphase-02 to draft-ietf-eppext-launchphase-03: 1. Added the "Implementation Status" section based on an action item from the eppext IETF-91 meeting. 2. Moved Section 7 "IANA Considerations" and Section 9 "Security Considerations" before Section 5 "Acknowledgements". Moved "Change Log" Section to end. 3. Updated the text for the Claims Check Form and the Claims Create Form to support checking for the need of the claims notice and passing the claims notice outside of the "claims" phase. 4. Added the new Trademark Check Form to support determining whether or not a trademark exists that matches the domain name independent of whether a claims notice is required on create. This was based on a request from Trung Tran and a discussion on the eppext mailing list. Please review draft-ietf-eppext-launchphase-03 and post any issues to the eppext mailing list. I want to thank everyone that has contributed to this draft version as well as all the past draft versions. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0

Re: [gtld-tech] Upcoming publication of updated Whois advisory
by Mats Dufberg Jan. 29, 2015

Jan. 29, 2015

Cyrus, Will it be possible to join that meeting remotely? If so, please send details to this list. Yours, Mats -- Mats Dufberg DNS Specialist, .SE (The Internet Infrastructure Foundation) Mobile: +46 73 065 3899 https://www.iis.se/en/ <http://www.iis.se/en> Från: Cyrus Namazi <cyrus.namazi(a)icann.org> Datum: Thursday 29 January 2015 02:07 Till: "gtld-tech(a)icann.org" <gtld-tech(a)icann.org> Kopia: Krista Papac <krista.papac(a)icann.org>, Mike Zupke <Mike.Zupke(a)icann.org>, Fabien Betremieux <fabien.betremieux(a)icann.org> Ämne: Re: [gtld-tech] Upcoming publication of updated Whois advisory Dear all; Following further correspondence and additional feedback from some of the stakeholders, we will hold off on publishing this advisory until after our face-to-face meeting at ICANN 52 in Singapore. Cheers, Cyrus Namazi ICANN From: Cyrus Namazi <cyrus.namazi(a)icann.org> Date: Friday, January 23, 2015 at 12:38 PM To: <gtld-tech(a)icann.org> Cc: Krista Papac <krista.papac(a)icann.org>, Mike Zupke <Mike.Zupke(a)icann.org>, Francisco Arias <francisco.arias(a)icann.org>, Fabien Betremieux <fabien.betremieux(a)icann.org> Subject: Upcoming publication of updated Whois advisory Dear RySG and RrSG members and colleagues, Attached please find the Whois advisory scorecard identifying those issues raised during ICANN’s numerous consultations with various interested parties over the course of the previous several months. The scorecard contains (among other things) a description of the issue raised and ICANN’s response. I thank the group members for their valuable contributions throughout these discussions. We have updated the draft advisory on those issues where there was room for interpretation. There are a small number of issues (three) that we think the Whois specifications do not allow for the changes some of you have proposed (rows 3, 8, and 15 of the attached scorecard). Consequently, there are only three issues in which we found no option but to maintain the current Whois advisory language. ICANN intends to publish a final advisory by the end of January with an implementation date of 31 July 2015, providing contracted parties ample time to implement any necessary changes. Thank you again for your time and your constructive inputs. Please let us know should you have any further questions or comments. Cheers, Cyrus Namazi Vice President | Domain Name Services | Global Domains Division 801 17th St NW, Suite 400 | Washington, DC 20006 USA +1.202.249.7543 Office | +1.408.421.6894 Mobile | cyrus.namazi(a)icann.org www.icann.org

1 0

Upcoming publication of updated Whois advisory
by Cyrus Namazi Jan. 29, 2015

Jan. 29, 2015

Dear RrSG and RrSG members and colleagues, Attached please find the Whois advisory scorecard identifying those issues raised during ICANN¹s numerous consultations with various interested parties over the course of the previous several months. The scorecard contains (among other things) a description of the issue raised and ICANN¹s response. I thank the group members for their valuable contributions throughout these discussions. We have updated the draft advisory on those issues where there was room for interpretation. There are a small number of issues (three) that we think the Whois specifications do not allow for the changes some of you have proposed (rows 3, 8, and 15 of the attached scorecard). Consequently, there are only three issues in which we found no option but to maintain the current Whois advisory language. ICANN intends to publish a final advisory by the end of January with an implementation date of 31 July 2015, providing contracted parties ample time to implement any necessary changes. Thank you again for your time and your constructive inputs. Please let us know should you have any further questions or comments. Cheers, Cyrus Namazi Vice President | Domain Name Services | Global Domains Division 801 17th St NW, Suite 400 | Washington, DC 20006 USA +1.202.249.7543 Office | +1.408.421.6894 Mobile | cyrus.namazi(a)icann.org www.icann.org

3 3

Final Call for Presentations for TechDay 53 at ICANN Singapore
by Dr Eberhard Lisse Jan. 27, 2015

Jan. 27, 2015

Hi, We have one 20 minute slot available for TechDay Singapore. The contact addresses are still: el(a)lisse.na and/or ondrej.filip(a)nic.cz or any of the lists this appears on, as I subscribe to them. greetings, el On 27/11/14 08:11, Dr Eberhard Lisse wrote: > > Hi, > > As usual we shall be organizing TechDay on Monday of the coming > ICANN meeting in Singapore. > > This time we are considering to try and demonstrate how to > generate DNSSEC keys in low cost smartcards which can be used in > openDNSSEC and the like. Not a signing ceremony proper, but with > a write-up so it is a step towards fully auditable procedures. > > We'll ask for a (or the same) room for Sunday (afternoon), so we > can practice :-)-O > > Please submit ideas for presentations to the list addresses where > this message appears or to any of the following email addresses: > > el(a)lisse.na ondrej.filip(a)nic.cz > > As we have a very small budget presenters are responsible for > their own transport and room and board, though we might be able to > assist the most riveting proposal :-)-O > > As the name suggests, talks must be of a technical (or > operational, perhaps even administrative) nature, and should > revolve around TLDs, but otherwise we are quite open. > > African participants are in particular encouraged to present, as > are of course Asians :-)-O > > Please forward this to gNSO and other lists as well :-)-O > > el > >

1 0

Re: [gtld-tech] WHOIS Clarification Advisory Scorecard
by Francisco Arias Jan. 16, 2015

Jan. 16, 2015

It seems I was missing text in row #7. Please use the attached. The only difference with v05 is adding one sentence in row #7. -- Francisco. On 1/7/15, 6:13 PM, "Francisco Arias" <francisco.arias(a)icann.org> wrote: >Dear colleagues, > >I’ve attached a scorecard with the list of issues that have been raised >and ICANN’s response. We provide rational in the cases in which we think >we should follow a different path than that proposed by the reporter(s) of >the issue. > >This is still a draft and we plan to host a conference call on next >Tuesday 13 January 2015 at 17:00 UTC for 60 minutes. We’ll share call >details in a separate email. > >Regards, > >-- >Francisco. >

2 3

WHOIS Clarification Advisory Scorecard
by Francisco Arias Jan. 8, 2015

Jan. 8, 2015

Dear colleagues, I’ve attached a scorecard with the list of issues that have been raised and ICANN’s response. We provide rational in the cases in which we think we should follow a different path than that proposed by the reporter(s) of the issue. This is still a draft and we plan to host a conference call on next Tuesday 13 January 2015 at 17:00 UTC for 60 minutes. We’ll share call details in a separate email. Regards, -- Francisco.

1 0

Whois advisory status
by Francisco Arias Dec. 22, 2014

Dec. 22, 2014

Dear colleagues, Just to let you know that ICANN is still reviewing the input received from you in writing and the teleconferences held this week. We plan to provide an status update in the first week of January. Best regards, -- Francisco.

2 1

Draft Updated WHOIS Clarification Advisory v.20141209
by Gustavo Lozano Dec. 21, 2014

Dec. 21, 2014

Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-201 4-09-12-en). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux(a)icann.org. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN

11 19

Re: [gtld-tech] host attributes issue
by Loesje Hermans Dec. 16, 2014

Dec. 16, 2014

Dear Francisco, After the conf call on the WHOIS clarifications I would like to clarify the issues we experience with host attributes and the current specs from ICANN about WHOIS. Since we are using the host attributes instead of host objects, we do not have a sponsoring registrar for hosts. According to the spec 4 of the registry agreement we do need to output these data in case of a nameserver query. In case we have a domain name in the zone that holds glue for a certain host, we could use the data of the sponsoring registrar of that domain name to output in the results of the nameserver query. But that will definitely not be the case for every host. What to display for the fields ‘Registrar’, ‘WHOIS server’ and ‘Referral URL’ in those cases? We also have no ROIDs for hosts. That leaves us with the only option of implementing clarification 32 and return all matching records. This will look weird since we have no data to fill in except for the Server name and the IP Address. As mentioned before, we do not have sponsoring registrars so the rest of the output fields will remain empty or will not be shown. Registrars will be enforced to specify glue when they specify a nameserver in the same domain as the domain name. Therefor we can only have multiple matches when performing a WHOIS query on IP address. Wouldn’t it be more logic to show all possible server names without any other keys in this case? Since the search was on IP, it is not really needed to output this IP address in every record. It would shorten the output and narrow it down to the relevant information. Kind regards, Loesje Hermans Functional Analyst +32 16 29 89 23 DNS Belgium vzw/asbl Ubicenter - Philipssite 5, bus 13 - 3001 Leuven www.dnsbelgium.be<http://www.dnsbelgium.be/> [cid:09ee086c0b7e41ef0f09e359060c1a61f817d422@zimbra]

1 0

Re: [gtld-tech] gtld-tech Digest, Vol 20, Issue 6
by Wodjenski, Sharon Dec. 12, 2014

Dec. 12, 2014

In addition to Alex's comments, I have the following questions/notes: I24. Fields in Whois output MUST NOT appear multiple times, unless otherwise explicitly specified. * Does this mean that only 1 Tech Contact can be displayed? If so, which one should be displayed if there are multiples? I was also especially confused by I29, 30, and 32 for reasons Alex mentions. II40. Responses to registrar object queries MUST show at least one admin contact and one technical contact. * Admin and Technical Contacts for Registrar are optional. So while there can be multiples, there also may be none. -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of gtld-tech-request(a)icann.org Sent: Friday, December 12, 2014 7:00 AM To: gtld-tech(a)icann.org Subject: gtld-tech Digest, Vol 20, Issue 6 Send gtld-tech mailing list submissions to gtld-tech(a)icann.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_l… or, via email, send a message with subject or body 'help' to gtld-tech-request(a)icann.org You can reach the person managing the list at gtld-tech-owner(a)icann.org When replying, please edit your Subject line so it is more specific than "Re: Contents of gtld-tech digest..." Today's Topics: 1. Re: Draft Updated WHOIS Clarification Advisory v.20141209 (Naoki Kambe) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Dec 2014 15:35:28 +0900 (JST) From: Naoki Kambe <kambe(a)jprs.co.jp> To: gtld-tech(a)icann.org Subject: Re: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Message-ID: <20141212.153528.200378422.kambe(a)jprs.co.jp> Content-Type: Text/Plain; charset=us-ascii Hi, One quick comment: One of the objectives of these clarifications is to retain the ability to easily parse the output. Interested users are encouraged to consider the clarifications below when developing parsers for RDDS output. The above objective doesn't seem much different from RDAP's one. I'm afraid the clarified WHOIS specification might reduce motivation to support RDAP. I'm curious about how we would migrate between WHOIS and RDAP in future. Regards, Naoki Kambe ------------------------------ _______________________________________________ gtld-tech mailing list gtld-tech(a)icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_l… End of gtld-tech Digest, Vol 20, Issue 6 ****************************************

1 0

WHOIS clarification needed for host attributes
by Loesje Hermans Nov. 28, 2014

Nov. 28, 2014

Hi all, According to the spec 4 of the registry agreement we should output following fields when querying for a name server: Registrar, WHOIS server and Referral URL. If I understand correctly they are also obligated and therefor cannot be left blank. Which data should be displayed for those fields when the registry uses host attributes? I cannot think of anything logic. Are there other registries using host attributes? Kind regards, Loesje Hermans Functional Analyst +32 16 29 89 23 DNS Belgium vzw/asbl Ubicenter - Philipssite 5, bus 13 - 3001 Leuven www.dnsbelgium.be<http://www.dnsbelgium.be/> [cid:09ee086c0b7e41ef0f09e359060c1a61f817d422@zimbra]

1 0

Call for Presentations for TechDay 26 at ICANN Singapore
by Dr Eberhard Lisse Nov. 27, 2014

Nov. 27, 2014

Hi, As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Singapore. This time we are considering to try and demonstrate how to generate DNSSEC keys in low cost smartcards which can be used in openDNSSEC and the like. Not a signing ceremony proper, but with a write-up so it is a step towards fully auditable procedures. We'll ask for a (or the same) room for Sunday (afternoon), so we can practice :-)-O Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz As we have a very small budget presenters are responsible for their own transport and room and board, though we might be able to assist the most riveting proposal :-)-O As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. African participants are in particular encouraged to present, as are of course Asians :-)-O Please forward this to gNSO and other lists as well :-)-O el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

Whois advisory feedback meeting @IETF91
by Gustavo Lozano Nov. 26, 2014

Nov. 26, 2014

Hello Colleagues, If you are at the IETF91, an informal meeting to get feedback about the Whois advisory published by ICANN (i.e. https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-201 4-09-12-en), will take place at Tapa Tower - Iolani 3 on Thursday (15.00 to 16.30 local time). Please send me a email if you are planing to assist in order to validate that the capacity of the room is sufficient. Regards, Gustavo ICAN

16 25

Name Collision Addendum - "Affected Names"
by Alexander Mayrhofer Nov. 25, 2014

Nov. 25, 2014

I've been reading through the Name Collision Occurrence Assessment Addendum, and one of the key issues seems to identify the "Affected Names" subset of the SLD block list. The Addendum specifies that "Affected Names" are "names that were included in the SLD Block list .... and recorded in the Trademark Clearinghouse ... that registry operator withheld from allocation during the Sunrise period", so it's a set operation between three lists. The SLD Block list as well as the list of names that registry operator withheld from allocation during Sunrise are known to the registry. However, the third list ("recorded in the Trademark Clearinghouse") is unknown to the registry operator, and the DNL is only an approximation. I do understand that such a list actually exists in the TMCH (the "SMDL", as far as i know?), however, this list is only available to registries that were granted a qualified launch program. Therefore, how would a registry that has not applied for a Qualified Launch Program access the SMDL to subsequently build the list of "Affected Names"? Does ICANN intend to release the SMDL to all registries? thanks, Alex

2 1

Almost Final Agenda for the joint DNS-OARC 25th TechDay
by Dr Eberhard W Lisse Nov. 5, 2014

Nov. 5, 2014

As usual I herewith post an almost final Agenda for the upcoming TechDay at the ICANN meeting in LA It is the 25th TechDay and will be held jointly with DNS-OARC. Please review https://indico.dns-oarc.net/conferenceTimeTable.py?confId=20#20141013.detai… for the definitive schedule on Sunday if it differs from this, their version is correct. If they differ on Monday this one or a subsequent one, is correct. Please do not however that somehow they'll manage to squeeze Roy Arends' most excellent Bumblebee demonstration in on Sunday. el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

2 1

FW: New Release of the Registry Reporting Interface
by Kal Feher Oct. 30, 2014

Oct. 30, 2014

Please note the upgrade time and the proposed functional changes. Please disseminate as appropriate. -- Kal Feher Enterprise Architect ARI Registry Services Level 8, 10 Queens Road Melbourne Victoria Australia 3004 Ph: +61 3 9866 3710 Fax: +61 3 9866 1970 Skype: Kal_ausreg Email: kal.feher(a)ariservices.com<mailto:kal.feher@ariservices.com> Web: www.ariservices.com<http://www.ariservices.com> For the latest Domain Name updates, follow us on Twitter @ARIservices The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain privileged and/or confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: registries-api-bounces(a)icann.org [mailto:registries-api-bounces@icann.org] On Behalf Of Brett Carr Sent: Wednesday, 29 October 2014 2:39 AM To: registries-api(a)icann.org Subject: [ICANN Ry/DEA API] New Release of the Registry Reporting Interface The Production Registry report Interface system will be upgraded to version 1.1.1 on Tuesday the 11th of November between 18:00-19:00 UTC *The following features will be added* Implement a HEAD on https://ry-api.icann.org/report/escrow-agent-notification/<TLD>/<d…> that provides the latest received escrow agent notification from the Data Escrow Agent. Implement a status report showing ok or fail for Escrow reports at /info/status/registry/<tld> Implement a status report showing ok or fail for Escrow reports at /info/status/dea/<tld> Implement HEAD on https://ry-api.icann.org/report/registry-functions-activity/TLD/date to allow simple monitoring Implement a HEAD on https://ry-api.icann.org/report/registry-escrow-report/TLD/date to allow simple monitoring Implement HEAD on https://ry-api.icann.org/report/registrar-transactions/TLD/date to allow simple monitoring Updates to the DNS registry reporting fields to allow higher numbers. *The following issues are resolved* Issue related to db locking when uploading several reports in parallel. A new internet draft will be published and posted on this mailing list prior to the release. - Brett Carr ICANN Technical Services UK (08:00-16:30 UTC)

1 1

Whois Clarifications confusion
by Kal Feher Oct. 16, 2014

Oct. 16, 2014

Hello GTLD-tech folks, I've been reviewing the Whois Clarifications communication from ICANN and I find myself frustrated at the lack of complete material and at the additional confusion it introduces. I'll list the concerns I have below. To which I'd invite any further clarifications from the people on this list: Clarification 1. The fields which are explicitly listed are allowed to be blank if they have no data. But what of those fields not listed? Are those fields not allowed to be blank? It should be noted that the EPP RFCs have "voice" as an optional element, yet it is excluded from Clarification 1 as one of the fields allowed to be blank. It concerns me that a clarification document is trying to introduce new behaviour. If OPTIONAL elements are to become required, a public discussion should be had. Already raised within this list is the confusion around name server addresses. And consider that if you allow multiple IP addresses as well as both IPv4 and IPv6 for each name server. Clarification 6. Clarification 7. If IP addresses are provided for name servers, should they appear directly after the name server or at the end of the output? If they appear at the end of RDDS output, it will be difficult for a consumer to know which IP address relates to which name server with any confidence. Note the comments for Clarification 1. There will be no reliable way to determine which IP address belongs to which name server. Clarification 8. Hosts may be added without IP addresses. Domains may be assigned to hosts without IP addresses. This is legal behaviour. Therefore requiring that a whois for a name server contain IP addresses, when system behaviour does not have a matching requirement, is contradictory. If system behaviour is to change, then it should done so through a public discussion. This is not a clarification, rather it is an alteration of existing behaviour. Clarification 10. The requirement to order fields as displayed, may need additional information and clarification. My literal interpretation of the requirements leads me to think that a second Admin or Tech contact would be displayed after the end of all RDDS output. An alternate reading is that we repeat each key in order eg: "Admin Name: AdminOne" followed by "Admin Name: AdminTwo". That is likely to confuse consumers significantly more than grouping a single complete Admin contact together followed by the next Admin contact and so on. It appears these clarifications have not been thought through in terms of they will be consumed and interpreted. Nor do they appear to have been developed with a view to ensuring that Registries and Registrars now have a complete picture of their Whois output obligations. I'm sure the clarifications are clear in the author's mind. But we as consumers of the document are left to guess. My experience with ICANN's interpretation of many elements of the Registry Agreement has been that they take an overly literal interpretation of what is written. I must therefore do the same when reading their documents. So if there are gaps, regardless of how obvious the solution might be, we have to insist that those gaps in clarity be provided to us. I echo Alexander's request that a complete specification, with no contradictions and no guesses, is required. Otherwise we'll be back here again a few months from now, clarifying the clarification document with further behaviour creep and with Registrars and Registries wasting further development resources. -- Kal Feher

2 4

Publishing of the Allocation Token EPP Extension IETF Draft
by Gould, James Oct. 9, 2014

Oct. 9, 2014

The first draft of the Allocation Token EPP Extension ( http://tools.ietf.org/html/draft-gould-allocation-token-00 ) has been submitted to the IETF. I co-authored this draft with Sharon Wodjenski and Trung Tran from Neustar to support the definition of an allocation token for allocating an object like a domain name. In one use case, the token can be used to support the releasing of reserved names via an external auction provider, where the domain names and tokens are provided to the auction provider, and the winning registrant of the auction will receive the token to pass through the registrar to the registry to allocate a domain name using a transform command like create, update, or transfer. Another use case is to use the token to authorize the allocation of domain names in a founder’s program. Other alternatives like leveraging the authinfo or leveraging one of the key, value pair extensions were considered, but we felt that having an explicit allocation token to authorize the allocation of an object was the cleanest approach. Please review the draft and provide any feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0

ICANNs WHOIS "clarifications" - overreaching and contradicting?
by Alexander Mayrhofer Sept. 18, 2014

Sept. 18, 2014

ICANN has published extensive "WHOIS Service Clarifications" on September 12, posted here: https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-201… We think that some of the points would warrant discussion among registries/registrars, as well as feedback from ICANN. Specifically, our points are: 1) Relation between current WHOIS requirements and RDAP implementation: Given the progress of RDAP in the IETF, we're wondering why ICANN can justify requesting the industry to put significant effort into modifying existing (and PDT-approved!) implementations of a protocal that ICANN probably intends to replace in the near future anyways. -> Therefore, Please provide a (if preliminary!) view on ICANN's intended roadmap on the future of RDDS protocols. 2) "Incremental", contradicting specifications: It seems like the "clarifications" contradict earlier requests by ICANN to modify the WHOIS service in at least one requirement: Clarification I.5 requires that Domain status field values conform to the respective EPP mappings. However, ICANNs earlier request in the "AWIP" (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en) requires that the line also includes a web link back to an information page - which means that the field value is required to carry cruft that is not contained in the EPP mappings, and hence violates ICANN's own "Clarification". I think this happens because of the "incremental" way the service is specified. -> Please provide an aggregated, complete, standalone specification without any contradicting requirements. 3) RAA specification affecting Registries: It seems weird that Registries should suddenly be subject to requirements that are included in the *RAA*. For example, see the "reseller" field in Clarification 1 - Why on earth would a *Registry* be required to display that field, which would contain information that only the registrar has access to? -> Please re-consider using the loophole of "Clarifications" to apply RAA requirements to registries 4) Redundant "empty" fields: Displaying an empty set of keys (eg. the field "Name Server" for domains, or the various DNSSEC-related fields) makes very little sense to me. Specifically for data relations that have a cardinality of 0..n, the requirement to include *all* fields seems overreaching. It might be sensible for fields that have a 1:1 relation, but artificially adding denormalized field sets for non-existing object relations is sloppy. Particularly because the only reasoning seems that people write cra..^H inadequate parsers. -> Please relax the respective requirement. 5) Data Protection requirements, EPP hidden fields vs. WHOIS: EPP allows for the "hiding" of certain fields in an contact object. The main use for this is (and will be) to achieve compliance with local data protection law, for example for EU based registries. However, the requirement in the Clarification document that "all fields MUST be shown", together with the provision that only "fields for which no information does exist in the registry" can be left empty effectively requires registries to breach the EPP "hidden field" settings. I'm not diving much deeper into the policy side of this, but preventing this from the *technical* side already looks like another loop hole to me. -> Please consider the option to exclude certain fields (particularly those affected by the EPP "hide" policy) on the technical level, to allow for doing so should a current or future policy allow (or a legal ruling to require) registries to do so. Feedback and discussion appreciated. thanks, Alex Mayrhofer Head of R&D nic.at / TLDBOX GmbH.

2 2

Registry Escrow Policy Object
by John Keating Sept. 15, 2014

Sept. 15, 2014

Hi, There seems to be a discrepancy between the way an Escrow Deposit Policy object is defined. In section 5.8.1 of version 5 of the Object mapping doc it's defined as: The OPTIONAL <policy> contains the following attributes: o An <element> that defines that the referenced <element> is REQUIRED. o <scope> that defines the XPath of the element referenced by <element>. Example of <rdePolicy:policy> object: <rdePolicy:policy scope="//rde:deposit/rde:contents/rdeDomain:domain" element="rdeDom:registrant" /> In rde-policy-1.0.xsd it's defined as: <element name="policy" type="rdePolicy:policyType" substitutionGroup="rde:content"/> <complexType name="policyType"> <complexContent> <extension base="rde:contentType"> <attribute name="element" type="anyURI" use="required"/> </extension> </complexContent> </complexType> Which says it has one attribute named 'element' of type 'anyURI', and the attribute 'scope' is not mentioned and so is not allowed. Has this difference in definitions been mentioned before? Thanks, John

3 10

Call for Presentations for TechDay 25 at ICANN LA
by Dr Eberhard Lisse Aug. 7, 2014

Aug. 7, 2014

Hi, As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Los Angeles. This will be the 25th TechDay and this time we'll do it jointly with DNS-OARC again (Sunday). See https://indico.dns-oarc.net/conferenceCFA.py?confId=20 We'll try to have one focus on large data and another one on security but this is not a condition. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz As we have a very small budget presenters are responsible for their own transport and room and board, though we might be able to assist the most riveting proposal :-)-O As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

Handling of "loc" and "int" contacts
by Alexander Mayrhofer July 18, 2014

July 18, 2014

All, We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements) we're looking into the options to move forward with allowing "loc" postalInfo types as well. I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback: - For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, "int" optional - For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc"?) - For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?) - Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables? Feedback appreciated :) thanks, Alex

6 5

Re: [gtld-tech] Almost Final Draft Agenda for TechDay London
by Dr Eberhard Lisse June 23, 2014

June 23, 2014

Please find enclosed and distribute widely. Times are more or less fixed now and for the speakers, please email your presentations in PDF without effects by Sunday evening London Time 2014-06-22 to kristina.nordstrom(a)icann.org so we can add them to the Adobe COnnect software for the remote participants. el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

3 2

Re: [gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Gould, James June 22, 2014

June 22, 2014

Elaine, Claims Lite consists of a LORDN like interface between the registries and the TMCH that provides a notice of the release and the allocation of reserves names with no front end claims to the registrar or registrant. The registries would need to implement this new LORDN like feed that will provide ICANN and the trademark holders systematic visibility into the reserved name activity. The release (i.e start of auction) of the reserved names would not show up in the zone files, so Claims Lite will provide more timely notice for the trademark holders. ICANN could use the feed to monitor the reserved name activity. The key is to not require a mix of registration flows for the registrars and registrants depending on whether the domain is a standard domain or a released reserved domain, which is disruptive to all parties. JG James F. Gould Principal Engineer Verisign jgould(a)verisign.com<mailto:jgould@verisign.com> On Jun 22, 2014, at 7:19 AM, "Elaine Pruis" <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: Hi James, Thanks for the reply. Sorry I've forgotten the details of "claims lite." Is that just notifying trademark holders when a name is registered right? If not, what does that require from the registry? Are claims still presented to the registrant? Elaine On Jun 20, 2014, at 9:23 AM, "Gould, James" <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: Elaine, Using a small subset of the list does reduce the probability of a match, but it does not remove it completely, meaning that the claims check still needs to be invoked by the registrar with the chance, yet very small, that the registrar would need to interface with the CNIS to present the claims notice and submit the claims acknowledgement on the create. Claims defines the general flow of a TLD, meaning a phase, and really is not a service that is applicable to a very small subset of domains of the TLD. I still prefer the "Claims Lite" option that does not require any front end interface changes, but does provide additional visibility to ICANN and the trademark holders for the releasing and allocation of reserved names. JG James F. Gould Principal Engineer Verisign jgould(a)verisign.com<mailto:jgould@verisign.com> On Jun 18, 2014, at 2:02 PM, "Elaine Pruis" <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: The easiest option is to verify against a small subset of the DNL Since the full DNL isn't checked, no claims will be presented after the mandatory 90 days for names that were available during that period. Claims would only be presented on names that come off the reserved list and are also on the DNL list. The "claims check" would be against a sub-list of the DNL list, instead of checking the entire list. This works for reserved names and for NXD names when they become available. This solution doesn't require much workflow change for registrars--just removing the "end date" for claims. It requires a bit of dev work for registry operators because we'd have to check a different list after the mandatory 90 days are up, but the cost would be significantly less. Jeff asked for some data to help guide the discuss, can we get an idea from the TMCH how many names on the DNL actually have been registered, and from registrars how many customers don't register after seeing a claims notice? We checked registrations in 90 TLDs against the DNL--the average number of names in our TLDs that are on the DNL is only 1%. This data is verifiable by checking zone files against the DNL. Considering the name collision block lists (the greatest source of reserved names, thousands in every TLD), on average only 0.47% of the names blocked for NXD are also on the DNL. Elaine Pruis Vice President, Operations ……………………………… …… …… elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161 <Donuts_Logo_Signature.png> On Jun 11, 2014, at 12:34 PM, Michele Neylon - Blacknight <michele(a)blacknight.com<mailto:michele@blacknight.com>> wrote: Jeff Sorry if I’m a bit thick here, but if you could clarify what you’re proposing for me it would be helpful. At the moment most new TLD registries seem to support a variant of the “claims check” which extends the standard “domain check”. Are you proposing removing that or tweaking it? Just trying to understand what you’re saying Thanks and regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: tmch-tech-bounces(a)icann.org<mailto:tmch-tech-bounces@icann.org> [mailto:tmch-tech-bounces@icann.org<mailto:tech-bounces@icann.org>] On Behalf OfJeffrey Eckhaus Sent: Tuesday, June 10, 2014 10:27 PM To: tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>; gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> Subject: [tmch-tech] Fwd: RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Hi all, We have been thinking a great deal about this and cannot come to any other conclusion is that this will be a major pain with little to no benefit to anyone involved. I like the idea of addressing this at a policy level to see if this can be removed or retracted based on information and evidence we have to date. How many claims notices have been served by the TMCH, how many registrations did not go through because the registrant did not agree to the Claims Notification. how many URS's have been sent? I believe that ICANN made this mandatory in the RPM "negotiations" and hopefully they can reverse this the same way they mandated it. Now that we are stuck with this , I think we still need to work towards a solution and think this is going to be driven by Registrars and how their solutions are setup. Even if a Registry decides to run eternal claims , if the registrar has their system set for .EXAMPLE TLD to only run claims for 90 days , it will be a bad user experience as the registration will fail, if the claims acknowledgment is not submitted. On the other side , if the Registrar has eternal claims running , then it will require all SLD's on the claims list to go through the TMCH, regardless if it is past 90 days. This is not a great option either , as it would add a tremendous workload to both Registries and Registrars and I do not see Registrars keeping this eternal claims on I think a possible solution for both sides is to have domain level claims checks. When a registrant searches for a domains at their favorite registrar , the registrar would send a claims check to the Registry. If the Registry has been in GA for over 90 days and the domain name was available the whole time (not on reserve) then it would return that there is no claims on this domain , even if it is actually in the TMCH. If it was just taken off reserve and is less than 90 days than it would come back with yes for Claims and the registrar would need to pull the claims notice and present it to the registrant. While this is still not ideal , it is the least burdensome method to registries and registrars and will cause the least amount of confusion for registrants Would love to hear any thoughts on this or any other proposals as we get closer to London meeting Jeff Begin forwarded message: From: Jeffrey Eckhaus <jeff(a)rightside.co<mailto:jeff@rightside.co>> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Date: June 10, 2014 at 2:19:49 PM PDT To: "Gould, James" <JGould(a)verisign.com<mailto:JGould@verisign.com>> Cc: Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>>, "tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>" <tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Hi all, We have been thinking a great deal about this and cannot come to any other conclusion is that this will be a major pain with little to no benefit to anyone involved. I like the idea of addressing this at a policy level to see if this can be removed or retracted based on information and evidence we have to date. How many claims notices have been served by the TMCH, how many registrations did not go through because the registrant did not agree to the Claims Notification. how many URS's have been sent? I believe that ICANN made this mandatory in the RPM "negotiations" and hopefully they can reverse this the same way they mandated it. Now that we are stuck with this , I think we still need to work towards a solution and think this is going to be driven by Registrars and how their solutions are setup. Even if a Registry decides to run eternal claims , if the registrar has their system set for .EXAMPLE TLD to only run claims for 90 days , it will be a bad user experience as the registration will fail, if the claims acknowledgment is not submitted. On the other side , if the Registrar has eternal claims running , then it will require all SLD's on the claims list to go through the TMCH, regardless if it is past 90 days. This is not a great option either , as it would add a tremendous workload to both Registries and Registrars and I do not see Registrars keeping this eternal claims on I think a possible solution for both sides is to have domain level claims checks. When a registrant searches for a domains at their favorite registrar , the registrar would send a claims check to the Registry. If the Registry has been in GA for over 90 days and the domain name was available the whole time (not on reserve) then it would return that there is no claims on this domain , even if it is actually in the TMCH. If it was just taken off reserve and is less than 90 days than it would come back with yes for Claims and the registrar would need to pull the claims notice and present it to the registrant. While this is still not ideal , it is the least burdensome method to registries and registrars and will cause the least amount of confusion for registrants Would love to hear any thoughts on this or any other proposals as we get closer to London meeting Jeff On Thu, May 29, 2014 at 1:38 PM, Gould, James <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: I agree with both Jeff and Elaine that having a discussion at the ICANN meeting along with further discussion on the list ahead of the meeting would be very useful. Can someone from ICANN respond to the request for adding this to the ICANN meeting agenda? Thanks, -- JG <image001.png> James Gould Principal Software Engineer jgould(a)verisign.com<mailto:jgould@verisign.com> 703-948-3271<tel:703-948-3271> (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> From: Jeffrey Eckhaus <jeff(a)rightside.co<mailto:jeff@rightside.co>> Date: Tuesday, May 27, 2014 at 4:13 PM To: Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>> Cc: "tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>" <tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Great idea Elaine. We are still thinking about this since we are looking at it from the Registry and Registrar side and the few weeks leading up to London would be helpful . I think we should continue discussion on the list leading up to the event , try to get to a plan right before event and maybe try to finalize something with ICANN in London Jeff On May 27, 2014, at 11:17 AM, Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: There are a few more options we can consider for Claims. Considering there is some dissent over how to apply the RPM requirements to reserved names it would be wise to meet in London for further discussion. That will give folks some time to come up with additional options. Would the ICANN person managing this list please arrange for that? Elaine Pruis Vice President, Operations ……………………………… …… …… elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161<tel:%2B1%20509-899-3161> <Donuts_Logo_Signature.png> On May 27, 2014, at 5:46 AM, Wil Tan <wil(a)cloudregistry.net<mailto:wil@cloudregistry.net>> wrote: On Thu, May 22, 2014 at 6:23 AM, Gould, James <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: I prefer option 2 for the “Allocation of the reserved names” problem. I prefer option 4 first, followed by option 3, for the “Handling the claims service for reserved names that have marks in the TMCH” problem. Running eternal claims services is clearly not a view shared by all registries. The middle ground -- asking registrars and registries to reactivate all the claims machinery for a subset of names -- presents a significant challenge. As such, I concur with option 4 or 3 for handling claims for reserved names with marks in TMCH. .wil Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

1 0

Re: [gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Gould, James June 20, 2014

June 20, 2014

Elaine, Using a small subset of the list does reduce the probability of a match, but it does not remove it completely, meaning that the claims check still needs to be invoked by the registrar with the chance, yet very small, that the registrar would need to interface with the CNIS to present the claims notice and submit the claims acknowledgement on the create. Claims defines the general flow of a TLD, meaning a phase, and really is not a service that is applicable to a very small subset of domains of the TLD. I still prefer the "Claims Lite" option that does not require any front end interface changes, but does provide additional visibility to ICANN and the trademark holders for the releasing and allocation of reserved names. JG James F. Gould Principal Engineer Verisign jgould(a)verisign.com<mailto:jgould@verisign.com> On Jun 18, 2014, at 2:02 PM, "Elaine Pruis" <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: The easiest option is to verify against a small subset of the DNL Since the full DNL isn't checked, no claims will be presented after the mandatory 90 days for names that were available during that period. Claims would only be presented on names that come off the reserved list and are also on the DNL list. The "claims check" would be against a sub-list of the DNL list, instead of checking the entire list. This works for reserved names and for NXD names when they become available. This solution doesn't require much workflow change for registrars--just removing the "end date" for claims. It requires a bit of dev work for registry operators because we'd have to check a different list after the mandatory 90 days are up, but the cost would be significantly less. Jeff asked for some data to help guide the discuss, can we get an idea from the TMCH how many names on the DNL actually have been registered, and from registrars how many customers don't register after seeing a claims notice? We checked registrations in 90 TLDs against the DNL--the average number of names in our TLDs that are on the DNL is only 1%. This data is verifiable by checking zone files against the DNL. Considering the name collision block lists (the greatest source of reserved names, thousands in every TLD), on average only 0.47% of the names blocked for NXD are also on the DNL. Elaine Pruis Vice President, Operations ……………………………… …… …… elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161 <Donuts_Logo_Signature.png> On Jun 11, 2014, at 12:34 PM, Michele Neylon - Blacknight <michele(a)blacknight.com<mailto:michele@blacknight.com>> wrote: Jeff Sorry if I’m a bit thick here, but if you could clarify what you’re proposing for me it would be helpful. At the moment most new TLD registries seem to support a variant of the “claims check” which extends the standard “domain check”. Are you proposing removing that or tweaking it? Just trying to understand what you’re saying Thanks and regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: tmch-tech-bounces(a)icann.org<mailto:tmch-tech-bounces@icann.org> [mailto:tmch-tech-bounces@icann.org<mailto:tech-bounces@icann.org>] On Behalf OfJeffrey Eckhaus Sent: Tuesday, June 10, 2014 10:27 PM To: tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>; gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> Subject: [tmch-tech] Fwd: RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Hi all, We have been thinking a great deal about this and cannot come to any other conclusion is that this will be a major pain with little to no benefit to anyone involved. I like the idea of addressing this at a policy level to see if this can be removed or retracted based on information and evidence we have to date. How many claims notices have been served by the TMCH, how many registrations did not go through because the registrant did not agree to the Claims Notification. how many URS's have been sent? I believe that ICANN made this mandatory in the RPM "negotiations" and hopefully they can reverse this the same way they mandated it. Now that we are stuck with this , I think we still need to work towards a solution and think this is going to be driven by Registrars and how their solutions are setup. Even if a Registry decides to run eternal claims , if the registrar has their system set for .EXAMPLE TLD to only run claims for 90 days , it will be a bad user experience as the registration will fail, if the claims acknowledgment is not submitted. On the other side , if the Registrar has eternal claims running , then it will require all SLD's on the claims list to go through the TMCH, regardless if it is past 90 days. This is not a great option either , as it would add a tremendous workload to both Registries and Registrars and I do not see Registrars keeping this eternal claims on I think a possible solution for both sides is to have domain level claims checks. When a registrant searches for a domains at their favorite registrar , the registrar would send a claims check to the Registry. If the Registry has been in GA for over 90 days and the domain name was available the whole time (not on reserve) then it would return that there is no claims on this domain , even if it is actually in the TMCH. If it was just taken off reserve and is less than 90 days than it would come back with yes for Claims and the registrar would need to pull the claims notice and present it to the registrant. While this is still not ideal , it is the least burdensome method to registries and registrars and will cause the least amount of confusion for registrants Would love to hear any thoughts on this or any other proposals as we get closer to London meeting Jeff Begin forwarded message: From: Jeffrey Eckhaus <jeff(a)rightside.co<mailto:jeff@rightside.co>> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Date: June 10, 2014 at 2:19:49 PM PDT To: "Gould, James" <JGould(a)verisign.com<mailto:JGould@verisign.com>> Cc: Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>>, "tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>" <tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Hi all, We have been thinking a great deal about this and cannot come to any other conclusion is that this will be a major pain with little to no benefit to anyone involved. I like the idea of addressing this at a policy level to see if this can be removed or retracted based on information and evidence we have to date. How many claims notices have been served by the TMCH, how many registrations did not go through because the registrant did not agree to the Claims Notification. how many URS's have been sent? I believe that ICANN made this mandatory in the RPM "negotiations" and hopefully they can reverse this the same way they mandated it. Now that we are stuck with this , I think we still need to work towards a solution and think this is going to be driven by Registrars and how their solutions are setup. Even if a Registry decides to run eternal claims , if the registrar has their system set for .EXAMPLE TLD to only run claims for 90 days , it will be a bad user experience as the registration will fail, if the claims acknowledgment is not submitted. On the other side , if the Registrar has eternal claims running , then it will require all SLD's on the claims list to go through the TMCH, regardless if it is past 90 days. This is not a great option either , as it would add a tremendous workload to both Registries and Registrars and I do not see Registrars keeping this eternal claims on I think a possible solution for both sides is to have domain level claims checks. When a registrant searches for a domains at their favorite registrar , the registrar would send a claims check to the Registry. If the Registry has been in GA for over 90 days and the domain name was available the whole time (not on reserve) then it would return that there is no claims on this domain , even if it is actually in the TMCH. If it was just taken off reserve and is less than 90 days than it would come back with yes for Claims and the registrar would need to pull the claims notice and present it to the registrant. While this is still not ideal , it is the least burdensome method to registries and registrars and will cause the least amount of confusion for registrants Would love to hear any thoughts on this or any other proposals as we get closer to London meeting Jeff On Thu, May 29, 2014 at 1:38 PM, Gould, James <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: I agree with both Jeff and Elaine that having a discussion at the ICANN meeting along with further discussion on the list ahead of the meeting would be very useful. Can someone from ICANN respond to the request for adding this to the ICANN meeting agenda? Thanks, -- JG <image001.png> James Gould Principal Software Engineer jgould(a)verisign.com<mailto:jgould@verisign.com> 703-948-3271<tel:703-948-3271> (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> From: Jeffrey Eckhaus <jeff(a)rightside.co<mailto:jeff@rightside.co>> Date: Tuesday, May 27, 2014 at 4:13 PM To: Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>> Cc: "tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>" <tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Great idea Elaine. We are still thinking about this since we are looking at it from the Registry and Registrar side and the few weeks leading up to London would be helpful . I think we should continue discussion on the list leading up to the event , try to get to a plan right before event and maybe try to finalize something with ICANN in London Jeff On May 27, 2014, at 11:17 AM, Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: There are a few more options we can consider for Claims. Considering there is some dissent over how to apply the RPM requirements to reserved names it would be wise to meet in London for further discussion. That will give folks some time to come up with additional options. Would the ICANN person managing this list please arrange for that? Elaine Pruis Vice President, Operations ……………………………… …… …… elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161<tel:%2B1%20509-899-3161> <Donuts_Logo_Signature.png> On May 27, 2014, at 5:46 AM, Wil Tan <wil(a)cloudregistry.net<mailto:wil@cloudregistry.net>> wrote: On Thu, May 22, 2014 at 6:23 AM, Gould, James <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: I prefer option 2 for the “Allocation of the reserved names” problem. I prefer option 4 first, followed by option 3, for the “Handling the claims service for reserved names that have marks in the TMCH” problem. Running eternal claims services is clearly not a view shared by all registries. The middle ground -- asking registrars and registries to reactivate all the claims machinery for a subset of names -- presents a significant challenge. As such, I concur with option 4 or 3 for handling claims for reserved names with marks in TMCH. .wil Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

1 0

Re: [gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Alexander Mayrhofer June 20, 2014

June 20, 2014

Elaine, it's not difficult at all. Where did you get the information from that the TMCH is using zone files instead of the LORDN reporting for extended claims`? Would appreciate a pointer. thanks, Alex Von: Elaine Pruis [mailto:elaine@donuts.co] Gesendet: Freitag, 20. Juni 2014 13:50 An: Alexander Mayrhofer Cc: Michele Neylon - Blacknight; tmch-tech(a)icann.org; gtld-tech(a)icann.org Betreff: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names How difficult is it to not submit the LORDN to the TMCH? Just make the claims available to the Registrar? Since the TMCH is offering extended claims by using the zone file to find names registered that are on the DNL list, they don't really need the LORDN after the 90 days, right? Elaine Pruis Vice President, Operations .................................... ...... ...... elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161 [cid:image001.png@01CF8C98.400068C0] On Jun 20, 2014, at 3:31 AM, Alexander Mayrhofer <alexander.mayrhofer(a)nic.at<mailto:alexander.mayrhofer@nic.at>> wrote: Elaine, all, The easiest option is to verify against a small subset of the DNL Since the full DNL isn't checked, no claims will be presented after the mandatory 90 days for names that were available during that period. Claims would only be presented on names that come off the reserved list and are also on the DNL list. The "claims check" would be against a sub-list of the DNL list, instead of checking the entire list. This works for reserved names and for NXD names when they become available. [Alexander Mayrhofer] That's exactly the way we will implement this. However, as we noticed recently, the TMCH *rejects* LORDN-entries for Claims once a registry moves beyond the "official" Claims Phase (as indicated on the ICANN startup schedule page). The TMCH responsds with an 4606 error ("TLD not in Sunrise or Claims"). That means that after the "official" 90-day Claims phase has ended for a TLD, the registry operator actually *can't* use the standard LORDN reporting process to submit domain names that required claims. Since i'm not aware of any other mechanism to report such Claims cases to the Clearinghouse, it seems to me that ICANN has created a requirement that doesn't seem to be implemented right now. So, without either: a) the TMCH accepting LORDN files *beyond* the standard claims phase (preferred, since it doesn't require *any* change on the registry/registrar side!) or b) ICANN/TMCH proposing a different solution for reporting of Claims associated with such "Late Claims" cases, i don't see how a registry could currently fulfil that requirement. We'll continue to send the respective reporting LORDN files, even though the TMCH does reject them. At least we tried. However, i'm definitely interested to join other Registry Backend Operators during the ICANN meeting if there's a discussion about this. Alex

1 0

Re: [gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Alexander Mayrhofer June 20, 2014

June 20, 2014

Elaine, all, The easiest option is to verify against a small subset of the DNL Since the full DNL isn't checked, no claims will be presented after the mandatory 90 days for names that were available during that period. Claims would only be presented on names that come off the reserved list and are also on the DNL list. The "claims check" would be against a sub-list of the DNL list, instead of checking the entire list. This works for reserved names and for NXD names when they become available. [Alexander Mayrhofer] That's exactly the way we will implement this. However, as we noticed recently, the TMCH *rejects* LORDN-entries for Claims once a registry moves beyond the "official" Claims Phase (as indicated on the ICANN startup schedule page). The TMCH responsds with an 4606 error ("TLD not in Sunrise or Claims"). That means that after the "official" 90-day Claims phase has ended for a TLD, the registry operator actually *can't* use the standard LORDN reporting process to submit domain names that required claims. Since i'm not aware of any other mechanism to report such Claims cases to the Clearinghouse, it seems to me that ICANN has created a requirement that doesn't seem to be implemented right now. So, without either: a) the TMCH accepting LORDN files *beyond* the standard claims phase (preferred, since it doesn't require *any* change on the registry/registrar side!) or b) ICANN/TMCH proposing a different solution for reporting of Claims associated with such "Late Claims" cases, i don't see how a registry could currently fulfil that requirement. We'll continue to send the respective reporting LORDN files, even though the TMCH does reject them. At least we tried. However, i'm definitely interested to join other Registry Backend Operators during the ICANN meeting if there's a discussion about this. Alex

1 0

RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Gould, James June 20, 2014

June 20, 2014

According to section 2.4.3 of the Rights Protection Mechanism (RPM) Requirements, it states: If Registry Operator reserves a domain name from registration in accordance with Section 2.6 of the Agreement and Specification 5 of the Agreement and thereafter (i) releases for Allocation or registration such reserved domain name at any time prior to the start date of the Claims Period, such domain name MUST be treated like any other domain name for any applicable Sunrise Period, Limited Registration Period, Launch Program or Claims Period, or (ii) releases for Allocation or registration such reserved domain name at any time following the start date of the Claims Period, such domain name MUST be subject to the Claims Services (as defined in Section 3) for a period of ninety (90) calendar days following the date Registry Operator releases such domain name for registration as long as the Trademark Clearinghouse (or any ICANN-designated successor thereto) remains in operation. For registries that plan on releasing domain names after the Claims Period, such as to support the release of premium domain names or 2 character domain names, they will have to support the Claims Services well past the Claims Period (potentially years). This represents a costly burden to the registries having to indefinitely download the DNL list, support the claims check, validating the domain creates against the DNL list for a subset of domain names, and support the TMCH LORDN interface. This also represents a costly burden to registrars or discourages registrar participation in supporting the release of reserved domain names. The registrars would need to know to use the claims check, use the CNIS for presenting the claims notice, and passing the claims acknowledgement indefinitely. Since this is a complex issue impacting registries and registrars, what approaches are being considered? Do the registries and registrars have any issues with supporting the Claims Service indefinitely? Please respond with your thoughts and concerns. Thanks, -- JG [cid:81958BBD-962A-4D7D-AB87-1A2BDB076D74] James Gould Principal Software Engineer jgould(a)verisign.com<mailto:jgould@verisign.com> 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

14 25

Re: [gtld-tech] gtld-tech Digest, Vol 13, Issue 1
by Dykes, Roy May 19, 2014

May 19, 2014

One way of dealing with this is to have the registry notify the TMCH (not using the LORDN file) but something similar to the TMCH if there's a registration of a domain name matching that of a claim. --Neustar Registry Product Management -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of gtld-tech-request(a)icann.org Sent: Monday, May 19, 2014 8:00 AM To: gtld-tech(a)icann.org Subject: gtld-tech Digest, Vol 13, Issue 1 Send gtld-tech mailing list submissions to gtld-tech(a)icann.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v1/url?u=https://mm.icann.org/mailman/lis… or, via email, send a message with subject or body 'help' to gtld-tech-request(a)icann.org You can reach the person managing the list at gtld-tech-owner(a)icann.org When replying, please edit your Subject line so it is more specific than "Re: Contents of gtld-tech digest..." Today's Topics: 1. RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names (Gould, James) ---------------------------------------------------------------------- Message: 1 Date: Mon, 19 May 2014 11:53:01 +0000 From: "Gould, James" <JGould(a)verisign.com> To: "gtld-tech(a)icann.org" <gtld-tech(a)icann.org>, "tmch-tech(a)icann.org" <tmch-tech(a)icann.org> Subject: [gtld-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Message-ID: <CF9F6885.5F071%jgould(a)verisign.com> Content-Type: text/plain; charset="utf-8" According to section 2.4.3 of the Rights Protection Mechanism (RPM) Requirements, it states: If Registry Operator reserves a domain name from registration in accordance with Section 2.6 of the Agreement and Specification 5 of the Agreement and thereafter (i) releases for Allocation or registration such reserved domain name at any time prior to the start date of the Claims Period, such domain name MUST be treated like any other domain name for any applicable Sunrise Period, Limited Registration Period, Launch Program or Claims Period, or (ii) releases for Allocation or registration such reserved domain name at any time following the start date of the Claims Period, such domain name MUST be subject to the Claims Services (as defined in Section 3) for a period of ninety (90) calendar days following the date Registry Operator releases such domain name for registration as long as the Trademark Clearinghouse (or any ICANN-designated successor thereto) remains in operation. For registries that plan on releasing domain names after the Claims Period, such as to support the release of premium domain names or 2 character domain names, they will have to support the Claims Services well past the Claims Period (potentially years). This represents a costly burden to the registries having to indefinitely download the DNL list, support the claims check, validating the domain creates against the DNL list for a subset of domain names, and support the TMCH LORDN interface. This also represents a costly burden to registrars or discourages registrar participation in supporting the release of reserved domain names. The registrars would need to know to use the claims check, use the CNIS for presenting the claims notice, and passing the claims acknowledgement indefinitely. Since this is a complex issue impacting registries and registrars, what approaches are being considered? Do the registries and registrars have any issues with supporting the Claims Service indefinitely? Please respond with your thoughts and concerns. Thanks, -- JG [cid:81958BBD-962A-4D7D-AB87-1A2BDB076D74] James Gould Principal Software Engineer jgould(a)verisign.com<mailto:jgould@verisign.com> 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com ?This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.?

3 2

Call for Presentations for TechDay at ICANN London
by Dr Eberhard W Lisse April 26, 2014

April 26, 2014

As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in London Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz This time we would like to have a focus on "(Big) Data", if possible, preferably DNS related data, ie query analysis etc, but also methods. As we have no budget presenters are responsible for their own transport and room and board. As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

spec5-reserved-names Legal Notice?
by Colosi, John April 22, 2014

April 22, 2014

Folks, Considering the spec5-reserved-names<https://github.com/centralnic/spec5-reserved-names> github repo that Gavin organized. I was wondering if the repo should have some kind of legal disclaimer saying essentially that folks should use it at their own risk. The community has done their best job of interpreting the ICANN guidelines, but it’s up to users to implement things in a way that meets their own contractual obligations. May be this isn’t necessary. Thoughts? -- John John Colosi Senior Manager of Product Development JColosi(a)Verisign.com m: 703-967-4062 t: 703-948-3211 12061 Bluemont Way, Reston VA 20190 VerisignInc.com<http://www.verisigninc.com/> [Verisign™] “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

2 1

Registrar IDs for new gTLDs
by Rubens Kuhl April 8, 2014

April 8, 2014

Hi there. After seeing Francisco Arias's presentation during ICANN Singapore, I had a doubt that one person also asked during the session: if the agreement only specifies 9999 as Registrar ID, can we divide the registrations depending on its billable nature between 9998 and 9999 without breaking the agreement ? Agreement text says: "02 iana-id For cases where the registry operator acts as registrar (i.e., without the use of an ICANN accredited registrar) 9999 should be used, otherwise the sponsoring Registrar IANA id should be used as specified in http://www.iana.org/assignments/registrar-ids " Any thoughts on that ? Any ICANN clarifications on this ? Tks, Rubens NIC.br

5 6

An on-going IETF discussion
by Edward Lewis April 7, 2014

April 7, 2014

Hi folks, (First time I’ve been on this list…but I think a few on the list already know me - I looked at some of the archives. I used to work with one gTLD, now I’m doing leg work for ICANN.) There’s a discussion in the IETF’s DNS Operations Working Group that people here might want to tune into and perhaps provide input. The message setting this up is here: http://www.ietf.org/mail-archive/web/dnsop/current/msg11543.html (And BTW, check this out too: http://www.ietf.org/mail-archive/web/dnsop/current/msg11542.html) The discussion is around an IETF *standards track* proposal to define a mechanism for how a registrant would signal to a registry that it has changed it’s NS set and/or glue records. The reason I’m bringing this up is: 1) The IETF believes that documenting this approach is better than not documenting, because they are concerned about delegations that do not fit the “ICANN model.” 2) The IETF wants and needs to hear from real operators. 3) In my opinion, this mechanism isn’t be workable for the gTLD environment. But, what do I know? So, I’m asking for those who have the time to take a look at the document and make comments on it - if not to the DNSOP list, to the DNSOP chairs or listed authors/editors. I don’t think the effort is dangerous, per se, but there are times that RFCs are pulled into RFPs for registry services. IMHO, I wouldn’t want this to become something asked of large registries. Perhaps I’m being paranoid, I say this to perhaps motivate people to read and comment. ;) Deadline is April 16 for the last call in the message (11543) above. Ed Lewis (aka edward.lewis(a)icann.org)

1 0

"zfa-passwords" vs CZDS
by Alexander Mayrhofer March 26, 2014

March 26, 2014

We're currently looking into submitting our first ICANN reports for the new gTLDs we host. One of the fields in the ICANN reporting data is the "zfa-passwords" field, which is supposed to contain the number of active users for the Zone File Access service of the TLD. In the light of CZDS, we're assuming that this field can be left set to "0", because there are no direct zone file access users with the individual registry (and that ICANN gathers the number of users directly from CZDS). Can someone (preferrably from ICANN) confirm this? thanks, Alex

9 14

Fwd: [dns-operations] DNS-OARC Spring 2014 Workshop - Warsaw, Poland, 10/11th May
by Mehmet Akcin March 18, 2014

March 18, 2014

FYI, A must attend event for DNS folks ---------- Forwarded message ---------- From: Keith Mitchell <keith(a)dns-oarc.net> Date: Mon, Mar 17, 2014 at 1:30 PM Subject: [dns-operations] DNS-OARC Spring 2014 Workshop - Warsaw, Poland, 10/11th May To: dns-operations(a)mail.dns-oarc.net DNS-OARC is pleased to announce that registration is now open for its 2014 Spring Workshop and Member EGM on the 10th and 11th May, in Warsaw, Poland. This will be held at the same location the subsequent RIPE68 meeting, and we're grateful to Microsoft for being our Platinum sponsor for this workshop. You can find more information about the workshop at: https://indico.dns-oarc.net//event/workshop-2014-05 and may register at: https://indico.dns-oarc.net//confRegistrationFormDisplay.py?confId=19 We still have room for some additional speakers on our programme, the submission deadline is THIS FRIDAY 21ST MARCH. For this workshop we are particularly interested in talks on DNS privacy and confidentiality, and DNS over alternative (non UDP) transports. Please submit your abstracts for review by the Programme Committee at: https://indico.dns-oarc.net//conferenceCFA.py?confId=19 OARC Workshop meetings are open to OARC members, presenters, and to all other parties interested in DNS operations and research, subject to available space. RIPE attendees are particularly welcome this time around. Workshop registration is free of charge, with priority given to OARC Members, Speakers, and Sponsors in the event of limited space. We are seeking additional sponsors for this meeting and a potential social event - if your organization is interested in sponsorship, please contact <sponsor(a)dns-oarc.net> for more information. For accommodation, travel and venue information, please see the RIPE68 meeting site at: https://ripe68.ripe.net/venue/meeting-venue/ Keith Mitchell OARC President _______________________________________________ dns-operations mailing list dns-operations(a)lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

1 0

Fwd: Almost Final Draft Agenda for TechDay Singapore
by Dr Eberhard Lisse March 15, 2014

March 15, 2014

Hi, we seem to have got us a draft agenda, which looks pretty close to the real thing, but times may change, or not. There is quite some stuff not just only for ccTLDs alone :-)-O so please spread the word. greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

2 1

Interfacing into ICANN's monitoring service provider?
by Alexander Mayrhofer Feb. 28, 2014

Feb. 28, 2014

Hi, back during the Prague ICANN meeting, i asked whether it will be possible for new gTLD registries (or their technical backend operators) to get data out from ICANN's own SLA monitoring service. In addition to a Registry's own monitoring system, this would provide a valuable additional "outside view" to the operations team. In discussion with other backend operators, i got the impression that this was something many of the community were interested in. The answer back then (from Francisco, if i remember correctly) was that "this was something that ICANN will look into". Was there any outcome regarding this? thanks, Alex

1 0

TMCH downtime
by Gavin Brown Feb. 17, 2014

Feb. 17, 2014

marksdb.org was down for a short period a little while ago - it's up now. The domain is delegated to ns1.sbp-isp.net and ns2.sbp-isp.net, with IPs 91.198.126.5 and 91.198.126.5 (why no IPv6?). Neither of these responded to DNS queries or pings. Given that those IPs are within the same /24 (hosted by EuroDNS, it seems) what's the betting that they're on the same box, which has crashed. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

3 2

Re: [gtld-tech] URS concerns
by Michele Neylon - Blacknight Feb. 14, 2014

Feb. 14, 2014

Wasn't wildcarding expressly forbidden in the contract? I know it referred in that context to the TLD and not a domain name, but surely the same logic applies .. -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Gavin Brown Sent: Friday, February 14, 2014 12:07 PM To: Kal Feher; gtld-tech(a)icann.org Subject: Re: [gtld-tech] URS concerns +1 on this. On 14/02/2014 05:21, Kal Feher wrote: > 3. I'd also suggest that the DNS server should not just wildcard all domain responses: > > dig @207.250.29.220 a icann.org +norec ;; flags: qr aa; QUERY: 1, > ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUESTION SECTION: > ;icann.org. IN A > ;; ANSWER SECTION: > icann.org. 86400 IN A 207.250.29.220 > ;; AUTHORITY SECTION: > . 86400 IN NS ns. > ;; ADDITIONAL SECTION: > ns. 86400 IN A 207.250.29.220 Also, using an IP address in an NS record. Very poor. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

1 0

URS concerns
by Kal Feher Feb. 14, 2014

Feb. 14, 2014

After the discussions we had on this list last year regarding URS procedures, I was curious to see what had been communicated to the URS provider and how they would implement their procedures. After looking at the implementation of the process (only from the outside so far), there appears to be a significant skills and awareness gap on the part of the URS provider. 1. Firstly, can someone please explain why they are providing IP addresses instead of nameservers? We _are_ in the domain name industry. It is also part of the technical procedures and just plain makes sense. 2. The zone configuration used by the URS provider appears to be a touch sloppy: dig ns facebok.pw @207.250.29.220 +norec ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;facebok.pw. IN NS ;; AUTHORITY SECTION: . 86400 IN SOA ns.yourhost.com. hostmaster.yourhost.com. 2008032701 28800 7200 604800 86400 It doesn't appear that the hosting provider "yourhost.com" has anything to do with this service. A quick google for "yourhost.com" does return a hit from "Starting and Building an Online Business for Dummies". I'd recommend a more appropriate configuration be used. 3. I'd also suggest that the DNS server should not just wildcard all domain responses: dig @207.250.29.220 a icann.org +norec ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUESTION SECTION: ;icann.org. IN A ;; ANSWER SECTION: icann.org. 86400 IN A 207.250.29.220 ;; AUTHORITY SECTION: . 86400 IN NS ns. ;; ADDITIONAL SECTION: ns. 86400 IN A 207.250.29.220 4. The DNS version appears to be creatively named: dig chaos txt version.bind @207.250.29.220 +short "get lost" 5. The website (and webserver), despite supporting ASP, appears to not do any programmatic evaluation of incoming requests: curl -H 'Host: icann.org' http://207.250.29.220/ <html> <head> <title>Suspended Site</title> </head> <body> <div style="text-align:center; background-color:#005FAD; color:white; font-size:40px;"> <p></p>This Site is Suspended </div> <br style="color:white;" /> <div style="background-color:#9AB3E5; font-size:30px;"> The Domain Name you've entered is not available. It has been taken down as a result of dispute resolution proceedings pursuant to the Uniform Rapid Suspension System (URS) Procedure and Rules. </div> <br style="color:white;" /> <div style="background-color:#D7E1F4; font-size:25px;"> For more information relating to the URS, please visit: <a href="http://newgtlds.icann.org/en/applicants/urs">http://newgtlds.icann.org/en/applicants/urs</a> </div> </body> </html> Kal Feher

2 1

Multi-TLD Registry Activity Report Counts
by Ben Levac Feb. 14, 2014

Feb. 14, 2014

I have a question about the expected content of the following fields of the Registry Functions Activity Report, but it probably applies to other fields in the report: 05 - whois-43-queries 06 - web-whois-queries We are currently operating a shared registry system which hosts multiple TLDs. The WHOIS service is also shared and answers queries for all of the TLDs supported by the system. In a system with only one TLD, I assume that these counters would include all WHOIS requests including invalid ones. In a shared registry system however, what should these counters contain? 1 - Only successful domain and host queries where we could determine the TLD. 2 - A sum of all queries (all TLDs would be reported with the same count). 3 - Some other formula. I'm not sure if this was ever discussed when creating these report definitions. I can't find any documentation of this scenario. Your help would be much appreciated. Cheers, Ben ________________________________ Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

1 0

Multi-TLD Registry Activity Report Counts
by Benoit Levac Feb. 14, 2014

Feb. 14, 2014

I have a question about the expected content of the following fields of the Registry Functions Activity Report, but it probably applies to other fields in the report: 05 - whois-43-queries 06 - web-whois-queries We are currently operating a shared registry system which hosts multiple TLDs. The WHOIS service is also shared and answers queries for all of the TLDs supported by the system. In a system with only one TLD, I assume that these counters would include all WHOIS requests including invalid ones. In a shared registry system however, what should these counters contain? 1 - Only successful domain and host queries where we could determine the TLD. 2 - A sum of all queries (all TLDs would be reported with the same count). 3 - Some other formula. I'm not sure if this was ever discussed when creating these report definitions. I can't find any documentation of this scenario. Your help would be much appreciated. Cheers, Ben -- Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

1 0

How to complain about http://newgtlds.icann.org/en/program-status/delegated-strings
by Chris Thompson Jan. 30, 2014

Jan. 30, 2014

Apologies for using this mailing list, but ICANN's feedback form proves useless for this purpose. The web page http://newgtlds.icann.org/en/program-status/delegated-strings is almost a week out of date (the latest 12 gTLDs are missing). Is anyone listening here capable of getting it unwedged again? -- Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk Roger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom.

3 2

DNS-OARC Call for Presentations
by Mehmet Akcin Jan. 30, 2014

Jan. 30, 2014

Call for Presentations - DNS-OARC Spring Workshop, May 2014 Next OARC Spring Workshop will take place in Warsaw, Poland on May 10th and 11th, the weekend before RIPE68. OARC is requesting proposals for presentations, with a preference for DNS privacy and confidentiality work and ideas, and DNS over alternative (non UDP) transports. This workshop continues OARC's tradition of having meetings include a strong operational component. Presentations from DNS operators are particularly welcome. We'll also gladly accept talks from DNS researchers, as well as any other DNS-related subjects such as tools, visualizations and data analysis. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Adopting practice from other conferences, a section of lightning talks will be added for short presentations. Workshop Milestones * 20 December 2013, Call for Presentations posted * 6 January 2014, Open for submissions * 1 March 2014, Deadline for submission * 28 March 2014, Final Program published * May 9 2014, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net/event/workshop-2014-05 at the beginning of January 2014. If you consider submitting a presentation, please let the Programme Committee know in advance to help us organize the presentations tracks. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissions at dns-oarc.net if you have questions or concerns. Mehmet Akcin, for the OARC Programme Committee (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.)

1 0

Call for Presentations for TechDay at ICANN Buenos Aires
by Dr Eberhard Lisse Jan. 28, 2014

Jan. 28, 2014

As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Buenos Aires. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz This time we would like to have an Latin American focus, if possible, hence Latin American presenters are strongly encouraged to come forward. As we have no budget presenters are responsible for their own transport and room and board. As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

3 6

Specification 5 - Invalid names
by Colosi, John Jan. 16, 2014

Jan. 16, 2014

These two names are in the S5.4.2.txt file: المملكة-المتحدة-لبريطانيا-العظمى-وآيرلندا-الشمالية соединенное-королевство-великобритании-и-северной-ирландии The resulting A-labels for these names are not valid in the DNS: xn--------lch4abbabcbafmcmf4d0bj3bg3f4c5a1a8y3aaefhfeceagqkzl0gzbxbdlm xn--------5veddhabeqmbbabeeb4cjbbabfcaznh0agq9bbaqifehdaegn7eolfhst1bm The A-labels are 70 characters long, and DNS requires a label to be no longer than 63 characters in length. I suggest these two string be removed from the file. -- John John Colosi Senior Manager of Product Development JColosi(a)Verisign.com m: 703-967-4062 t: 703-948-3211 12061 Bluemont Way, Reston VA 20190 VerisignInc.com “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

2 1

CA's accepting CSR's for nic.<new gTLDs> yet?
by Alexander Mayrhofer Jan. 14, 2014

Jan. 14, 2014

Hi, has anybody had success with convincing one of the well-know Certification Authorities to issue a certificate for names under nic.<newgTLD> yet? I understand that most CA's have either not whitelisted the TLDs - another factor is that in the light of the name collision discussions, they would probably confuse such requests with (now banned) "internal certificates".. Pointers and anecdotal experience appreciated :) thanks, Alex

2 2

Specification 5 - Country names... again..
by Alexander Mayrhofer Jan. 13, 2014

Jan. 13, 2014

I've started looking at the two PDFs of country names that ICANN mandates us to reserve in Section 4.2 and 4.3 of Specification 5 of the Registry Agreement. I have a couple of comments on this: a) I can only guess whether or not the PDFs that i use (http://unstats.un.org/unsd/geoinfo/ungegn/docs/ungegn-tech-ref-manual_M87_c… and http://unstats.un.org/unsd/geoinfo/UNGEGN/docs/26th-gegn-docs/WP/WP54_UNGEG…) are the correct ones, since ICANN failed to include a reference to the documents in the Agreement. b) Extracting names from those documents (particularly in scripts that i'm not familiar with) is absolutely horrible, and will likely lead to interopability problems between registries. c) The mapping of the strings required to be reserved to the actual A-Label is undefined. Therefore, could ICANN please look into creating an reservation list covering these two requirements, and publish that list as a recommended way to implement the two requirements? ICANN could use a tiny tiny fraction of the application fees to contract someone to create an authoritative list of names to be reserved - Or, maybe as a secondary option in case there should be insufficient budget, allocate resources from their "Languages Services Department" http://blog.icann.org/2013/10/introducing-the-language-services-team/ to create this list? I'm sure that many members of the community would welcome this as a useful contribution to ensure a unified approach to those requirements. thanks, Alex Mayrhofer Head of R&D nic.at

8 19

Re: [gtld-tech] Specification 5 - Country names... again..
by Alexander Mayrhofer Dec. 5, 2013

Dec. 5, 2013

John, James, I have a few more comments on the lists that we have been collecting on the Github site. Specifically: > 2. I've attached Verisign's spreadsheet for section 5.4.3 (UN Member States > and translations). There are 7 languages (including both traditional and > simplified Chinese). Spaces and hyphens are tricky. The issue is that > translation engines (here I mostly use Google's service) will often handle > spaces intelligently. For instance, "Central African Republic" translated to > Russian becomes "Центрально-Африканская Республика". That is, a > hyphen is introduced for the first space. I presume this is a standard for the > "Central" modifier. You could choose to create a variant without any > hyphens or spaces, or you could try all the permutations of hyphens and > spaces. Instead of heading down that rabbit hole, we elected to yield to the > translation wherever possible. But we'll respect the group decision and > update our implementation accordingly. On Specification 5.4.3: --------------------------- The agreement says "the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;" I do understand that there is an offical document from the UN that provides translations for those country names. The URL (at least the one i've been using) is: http://unstats.un.org/unsd/geoinfo/UNGEGN/docs/26th-gegn-docs/WP/WP54_UNGEG… I do understand that the above document already contains readily translated / agreed country names for the six UN languages, as required in 5.4.2. However, i do also understand that the list that's now in the Github repository was actually produced using automated translation, which potentially could yield different results compared to extracting the list of country names from the document (or the respective source file)? Therefore, could you please clarify whether the file that's now on the Github was produced by translation engines, or taken from said document? I think that's a significant impact on whether or not that file is usable to cover ICANN's requirement. On Specification 5.4.2: --------------------------- The agreement requires "the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World". Looking at the respective document (http://unstats.un.org/unsd/geoinfo/ungegn/docs/pubs/UNGEGN%20tech%20ref%20m…) the actual list (starting on page 185) contains several columns: - ISO3166 code - COUNTRY- English (UN) - ISO Code; language - Short Name - Formal Name It is unclear to me which of the various columns is to be considered for the reserved names list. Candidates would be the "Country-ENGLISH" (although that is likely already covered by the UN list described in 5.4.3?), the "Short Name", and the "Formal Name". However, looking at the file that is now uploaded on the github for the respective Specification (https://github.com/centralnic/spec5-reserved-names/blob/master/S5.4.2.txt) it doesn't seem to correspond to *any* of these columns. for example, the Entry for "AF" (assumed) in the file lists "afganistán" does not exist in the PDF - in neither of the respective columns. I'm slightly worried that therefore the list that is currently uploaded does not fulfill the respective requirement (besides that i think the original requirement is highly inprecise and hence disputable).. Do i look at the wrong files? Do people interpret the requirements in a different form? Any comments appreciated... thanks, Alex

4 6

Version 1.0 of the URS technical requirements published
by Gustavo Lozano Dec. 4, 2013

Dec. 4, 2013

Colleagues, Version 1.0 of the URS technical requirements document has been published at: http://newgtlds.icann.org/en/applicants/urs The direct download link of the document is: http://newgtlds.icann.org/en/applicants/urs/tech-requirements-17oct13-en.pdf Regards, Gustavo

3 3

Re: [gtld-tech] gtld-tech Digest, Vol 7, Issue 17
by Dykes, Roy Nov. 26, 2013

Nov. 26, 2013

Alexander/all, Thanks for the note. I also opened Ticket 00113354 with ICANN on 11/14/2013 (see attached) on this very same issue. We need definitive, blessed by ICANN lists for these two sections (4.2 and 4.3) of Spec 5 so that we know exactly what to block and have assurances that all other backends are blocking the identical SLDs. As of Tues. (11/26), there has not been a response to my ticket. --Roy Dykes Neustar Registry Product Management -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of gtld-tech-request(a)icann.org Sent: Monday, November 25, 2013 11:59 AM To: gtld-tech(a)icann.org Subject: gtld-tech Digest, Vol 7, Issue 17 Send gtld-tech mailing list submissions to gtld-tech(a)icann.org To subscribe or unsubscribe via the World Wide Web, visit https://mm.icann.org/mailman/listinfo/gtld-tech or, via email, send a message with subject or body 'help' to gtld-tech-request(a)icann.org You can reach the person managing the list at gtld-tech-owner(a)icann.org When replying, please edit your Subject line so it is more specific than "Re: Contents of gtld-tech digest..." Today's Topics: 1. Specification 5 - Country names... again.. (Alexander Mayrhofer) 2. Re: Specification 5 - Country names... again.. (Luis Mu?oz) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Nov 2013 16:18:46 +0000 From: Alexander Mayrhofer <alexander.mayrhofer(a)nic.at> To: "gtld-tech(a)icann.org" <gtld-tech(a)icann.org> Subject: [gtld-tech] Specification 5 - Country names... again.. Message-ID: <19F54F2956911544A32543B8A9BDE0750A37DB41(a)NICS-EXCH2.sbg.nic.at> Content-Type: text/plain; charset="us-ascii" I've started looking at the two PDFs of country names that ICANN mandates us to reserve in Section 4.2 and 4.3 of Specification 5 of the Registry Agreement. I have a couple of comments on this: a) I can only guess whether or not the PDFs that i use (http://unstats.un.org/unsd/geoinfo/ungegn/docs/ungegn-tech-ref-manual_M87_c… and http://unstats.un.org/unsd/geoinfo/UNGEGN/docs/26th-gegn-docs/WP/WP54_UNGEG…) are the correct ones, since ICANN failed to include a reference to the documents in the Agreement. b) Extracting names from those documents (particularly in scripts that i'm not familiar with) is absolutely horrible, and will likely lead to interopability problems between registries. c) The mapping of the strings required to be reserved to the actual A-Label is undefined. Therefore, could ICANN please look into creating an reservation list covering these two requirements, and publish that list as a recommended way to implement the two requirements? ICANN could use a tiny tiny fraction of the application fees to contract someone to create an authoritative list of names to be reserved - Or, maybe as a secondary option in case there should be insufficient budget, allocate resources from their "Languages Services Department" http://blog.icann.org/2013/10/introducing-the-language-services-team/ to create this list? I'm sure that many members of the community would welcome this as a useful contribution to ensure a unified approach to those requirements. thanks, Alex Mayrhofer Head of R&D nic.at ------------------------------ Message: 2 Date: Mon, 25 Nov 2013 11:58:20 -0500 From: Luis Mu?oz <lem(a)isc.org> To: Alexander Mayrhofer <alexander.mayrhofer(a)nic.at> Cc: "gtld-tech(a)icann.org" <gtld-tech(a)icann.org> Subject: Re: [gtld-tech] Specification 5 - Country names... again.. Message-ID: <4BAD47C7-979B-406B-9C39-0C4490F87648(a)isc.org> Content-Type: text/plain; charset="us-ascii" On Nov 25, 2013, at 11:18 AM, Alexander Mayrhofer wrote: > I've started looking at the two PDFs of country names that ICANN mandates us to reserve in Section 4.2 and 4.3 of Specification 5 of the Registry Agreement. I have a couple of comments on this: > > a) I can only guess whether or not the PDFs that i use (http://unstats.un.org/unsd/geoinfo/ungegn/docs/ungegn-tech-ref-manual_M87_c… and http://unstats.un.org/unsd/geoinfo/UNGEGN/docs/26th-gegn-docs/WP/WP54_UNGEG…) are the correct ones, since ICANN failed to include a reference to the documents in the Agreement. > > b) Extracting names from those documents (particularly in scripts that i'm not familiar with) is absolutely horrible, and will likely lead to interopability problems between registries. > > c) The mapping of the strings required to be reserved to the actual A-Label is undefined. > > Therefore, could ICANN please look into creating an reservation list covering these two requirements, and publish that list as a recommended way to implement the two requirements? > > ICANN could use a tiny tiny fraction of the application fees to contract someone to create an authoritative list of names to be reserved - Or, maybe as a secondary option in case there should be insufficient budget, allocate resources from their "Languages Services Department" http://blog.icann.org/2013/10/introducing-the-language-services-team/ to create this list? > > I'm sure that many members of the community would welcome this as a useful contribution to ensure a unified approach to those requirements. ++ I went to the trouble of interacting with the primary sources and obtaining workable references because what is published is quite hard to coerce into the format we all need it. In the process I received rather amusing responses from various organizations that should know better. I'm attaching a list that should be easier to work with. Rather than simply sending them to this mailing list, wouldn't it be better to setup a github repo or similar device so that updates can be made to the data, and we all have access to the latest version of the common work? In the meanwhile, comments and additions are welcome. Best regards -lem

1 0

Re: [gtld-tech] Specification 5 - Country names... again..
by Michele Neylon - Blacknight Nov. 25, 2013

Nov. 25, 2013

Gavin Nice work. You should probably add "eire" as the alternative for "Ireland", as our government tends to like having both the Irish and English versions Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ________________________________________ From: gtld-tech-bounces(a)icann.org [gtld-tech-bounces(a)icann.org] on behalf of Gavin Brown [gavin.brown(a)centralnic.com] Sent: 25 November 2013 17:09 To: Luis Muñoz; Alexander Mayrhofer Cc: gtld-tech(a)icann.org Subject: Re: [gtld-tech] Specification 5 - Country names... again.. > I went to the trouble of interacting with the primary sources and obtaining workable references because what is published is quite hard to coerce into the format we all need it. In the process I received rather amusing responses from various organizations that should know better. I'm attaching a list that should be easier to work with. > > Rather than simply sending them to this mailing list, wouldn't it be better to setup a github repo or similar device so that updates can be made to the data, and we all have access to the latest version of the common work? In the meanwhile, comments and additions are welcome. I agree: https://github.com/centralnic/spec5-reserved-names I've added your list, plus the file I was working on. Let's see if we can work out a format that makes sense for this - JSON? XML? YAML? G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

1 0

Delegated strings: WHOIS & SLAs...
by Alexander Mayrhofer Nov. 21, 2013

Nov. 21, 2013

Looking at some of the recently delegated new gTLDs, i was very surprised to learn that the WHOIS service is unreachable for some of those TLDs (which makes me wonder how they passed PDT, or why the service degraded since then?). Anyways, since WHOIS is included in the SLA requirements of ICANN, this makes me also wonder when the SLA actually "kicks in", and, whether the SLAs are actually being measured right now by ICANN ... Any information about this? Alex

13 33

Update to reserved names list for new gTLDs
by Francisco Arias Nov. 21, 2013

Nov. 21, 2013

Colleagues, This is a heads up that we have updated the list of reserved names for new gTLDs at http://www.icann.org/en/resources/registries/reserved Formal notifications to contracted parties will go out shortly. Regards, -- Francisco Arias gTLD Registry Technical Liaison ICANN PGP: 1FDE 819F 7BEC 1CB2 127E EE54 9A4D 337B D510 E397

9 12

IANA ID for "internal" registrar
by Alexander Mayrhofer Nov. 21, 2013

Nov. 21, 2013

I'm wondering what IANA ID "internal" registrars (such as those owning the "nic" 2nd-level domain, or any registrars used for monitoring) should be allocated? I understand that there was some documentation that recommended using 9999 for the "registry" registrar. But since more registrars are likely needed (such as the ICANN monitoring registrar), we probably need more than one ID. Any recommendations on that? Otherwise, we'll proceed with counting "up" from 9999.. or down... or negative IDs? ;) Alex

4 5

Re: [gtld-tech] Delegated strings: WHOIS & SLAs...
by Chris Thompson Nov. 21, 2013

Nov. 21, 2013

Is the ban on non-apex RRs (such as an SRV for _nicname._tcp.[TLD]) other than delegations at all driven by the fear that too much of the world is using BIND's "root-delegation-only" with an exclude list that they won't change to include new gTLDs (or any equivalent in other recursive nameserver implementations)? We all remember the incident(s) that caused that option to be invented, but I fear it is going to cause trouble for a long time to come. -- Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk Roger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom.

1 0

Re: [gtld-tech] Delegated strings: WHOIS & SLAs...
by Michele Neylon - Blacknight Nov. 20, 2013

Nov. 20, 2013

They aren't obliged to use nic.tld afaik - the whois server is specified in their respective IANA entry -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ________________________________________ From: gtld-tech-bounces(a)icann.org [gtld-tech-bounces(a)icann.org] on behalf of Alexander Mayrhofer [alexander.mayrhofer(a)nic.at] Sent: 20 November 2013 15:25 To: Rubens Kuhl Cc: gtld-tech(a)icann.org Subject: Re: [gtld-tech] Delegated strings: WHOIS & SLAs... I'm using whois.nic.<TLD> - and, yes, nic.<TLD> is properly delegated and reachable in that case, but "whois.nic.<tld>" returns an NXDOMAIN. My understanding is that ICANN requires the WHOIS service to be offered under that hostname... See the respective specification in the AGB.. Indeed, the IANA record shows a different server - so, do i understand correctly that you can actually submit to IANA a different WHOIS server than the one required by ICANN? Can anyone who's already delegated confirm this? Alex > -----Ursprüngliche Nachricht----- > Von: Rubens Kuhl [mailto:rubensk@nic.br] > Gesendet: Mittwoch, 20. November 2013 15:02 > An: Alexander Mayrhofer > Cc: gtld-tech(a)icann.org > Betreff: Re: [gtld-tech] Delegated strings: WHOIS & SLAs... > > > Are you using whois.nic.<TLD> or the WHOIS server mentioned at > http://www.iana.org/whois?q=<TLD> ? > > > Rubens > > On Nov 20, 2013, at 10:53 AM, Alexander Mayrhofer > <alexander.mayrhofer(a)nic.at> wrote: > > > > > Looking at some of the recently delegated new gTLDs, i was very surprised > to learn that the WHOIS service is unreachable for some of those TLDs (which > makes me wonder how they passed PDT, or why the service degraded since > then?). Anyways, since WHOIS is included in the SLA requirements of ICANN, > this makes me also wonder when the SLA actually "kicks in", and, whether > the SLAs are actually being measured right now by ICANN ... > > > > Any information about this? > > > > Alex > >

3 2

Re: [gtld-tech] Delegated strings: WHOIS & SLAs...
by Michele Neylon - Blacknight Nov. 20, 2013

Nov. 20, 2013

Chicken and egg, as Rubens explained .. -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ________________________________________ From: Alexander Mayrhofer [alexander.mayrhofer(a)nic.at] Sent: 20 November 2013 15:34 To: Michele Neylon - Blacknight; Rubens Kuhl Cc: gtld-tech(a)icann.org Subject: AW: [gtld-tech] Delegated strings: WHOIS & SLAs... The Registry Agreement is quite clear on this, though: "Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web based Directory Service at <whois.nic.TLD> providing free public query based access to at least the following elements in the following format." Strictly speaking, it hence looks like running the WHOIS service under a different hostname would constitute a violation of the Registry agreement? Alex > -----Ursprüngliche Nachricht----- > Von: Michele Neylon - Blacknight [mailto:michele@blacknight.com] > Gesendet: Mittwoch, 20. November 2013 16:28 > An: Alexander Mayrhofer; Rubens Kuhl > Cc: gtld-tech(a)icann.org > Betreff: RE: [gtld-tech] Delegated strings: WHOIS & SLAs... > > They aren't obliged to use nic.tld afaik - the whois server is specified in their > respective IANA entry > > -- > Mr Michele Neylon > Blacknight Solutions > Hosting & Colocation, Domains > http://www.blacknight.co/ > http://blog.blacknight.com/ > http://www.technology.ie > Intl. +353 (0) 59 9183072 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Fax. +353 (0) 1 4811 763 > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > ________________________________________ > From: gtld-tech-bounces(a)icann.org [gtld-tech-bounces(a)icann.org] on > behalf of Alexander Mayrhofer [alexander.mayrhofer(a)nic.at] > Sent: 20 November 2013 15:25 > To: Rubens Kuhl > Cc: gtld-tech(a)icann.org > Subject: Re: [gtld-tech] Delegated strings: WHOIS & SLAs... > > I'm using whois.nic.<TLD> - and, yes, nic.<TLD> is properly delegated and > reachable in that case, but "whois.nic.<tld>" returns an NXDOMAIN. My > understanding is that ICANN requires the WHOIS service to be offered under > that hostname... See the respective specification in the AGB.. > > Indeed, the IANA record shows a different server - so, do i understand > correctly that you can actually submit to IANA a different WHOIS server than > the one required by ICANN? Can anyone who's already delegated confirm > this? > > Alex > > > -----Ursprüngliche Nachricht----- > > Von: Rubens Kuhl [mailto:rubensk@nic.br] > > Gesendet: Mittwoch, 20. November 2013 15:02 > > An: Alexander Mayrhofer > > Cc: gtld-tech(a)icann.org > > Betreff: Re: [gtld-tech] Delegated strings: WHOIS & SLAs... > > > > > > Are you using whois.nic.<TLD> or the WHOIS server mentioned at > > http://www.iana.org/whois?q=<TLD> ? > > > > > > Rubens > > > > On Nov 20, 2013, at 10:53 AM, Alexander Mayrhofer > > <alexander.mayrhofer(a)nic.at> wrote: > > > > > > > > Looking at some of the recently delegated new gTLDs, i was very > > > surprised > > to learn that the WHOIS service is unreachable for some of those TLDs > > (which makes me wonder how they passed PDT, or why the service > > degraded since then?). Anyways, since WHOIS is included in the SLA > > requirements of ICANN, this makes me also wonder when the SLA actually > > "kicks in", and, whether the SLAs are actually being measured right now by > ICANN ... > > > > > > Any information about this? > > > > > > Alex > > >

2 1

Re: [gtld-tech] Delegated strings: WHOIS & SLAs...
by Michele Neylon - Blacknight Nov. 20, 2013

Nov. 20, 2013

Any I've tested had functioning whois - do you have any examples of broken ones? -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ________________________________________ From: gtld-tech-bounces(a)icann.org [gtld-tech-bounces(a)icann.org] on behalf of Alexander Mayrhofer [alexander.mayrhofer(a)nic.at] Sent: 20 November 2013 13:53 To: gtld-tech(a)icann.org Subject: [gtld-tech] Delegated strings: WHOIS & SLAs... Looking at some of the recently delegated new gTLDs, i was very surprised to learn that the WHOIS service is unreachable for some of those TLDs (which makes me wonder how they passed PDT, or why the service degraded since then?). Anyways, since WHOIS is included in the SLA requirements of ICANN, this makes me also wonder when the SLA actually "kicks in", and, whether the SLAs are actually being measured right now by ICANN ... Any information about this? Alex

1 0

Agenda for TechDay Buenos Aires
by Dr Eberhard W Lisse Nov. 17, 2013

Nov. 17, 2013

Please find enclosed the agenda for TechDay Buenos Aires. Can all the speakers who have not done so please forward their final presentations as PDF without animations or transition effects to Kristina Nordstrom at kristina.nordstrom(a)icann.org before 17:00 today local time so she can load them into the Adobe Connect software for the remote participants. greetings, el

1 0

TMCH SMD Application Priorities
by Mike O'Connell Nov. 12, 2013

Nov. 12, 2013

All, I know this might be more of a policy than a technical issue but I had some questions around application priorities. We're going to be ranking applications based on a few different factors in the following priorities. Regional Trade Marks, Regional Court Orders, Treaties or Statutes Other Trade Marks Other Court Orders Regional Unregistered Marks Other Unregistered Marks Where 'regional' is the region for which the gTLD is intended to service. The technical part comes from the SMD and the TreatyOrStatute section, specifically the 'protection' element. There exist certain 'global' treaties or statutes, how will these be represented in the SMD? Will SMDs for 'champagne' or 'bordeaux' have a protection 'cc' entry for all countries of the world. I would like to, ideally, split the 'Treaties or Statues' on 'Regional' and 'Other' but I'm not sure about the 'global' treaty and statute's protection. Apologies if this is slightly off topic for the gtld-tech list, I couldn't really place the query between tmch-tech and gtld-tech. Sincerely, -- Mike

1 0

Bar BoF at IETF 88, anyone?
by Alexander Mayrhofer Nov. 8, 2013

Nov. 8, 2013

Hi, Is anybody interesting in a bar BoF / lunch around (technical) new gTLD topics? Please respond in PM with possible date/time, and i'd arrange something. Alex

3 8

IDN Tables
by John Hollifield Oct. 22, 2013

Oct. 22, 2013

Hi I am a bit confused about how our IDN table should be structured with respect to variants as I feel section 5, A Model Table Format, of RFC 4290 (https://www.ietf.org/rfc/rfc4290.txt) is a bit ambiguous. I am therefore hoping there is somebody out there with experience of these things that could help me. I have looked at other IDN tables but none seem to help me with the issue below. The RFC states: Each non-comment line in the table starts with the character that is allowed in the registry and expected to be used in registrations, which is also called the "base character". It then goes on to say: If the base character has any variants, the base character is followed by a vertical bar character ("|", ASCII 0x7C) and the variant string. If the base character has more than one variant, the variants are separated by a colon (":", ASCII 0x3A). So if I have the following characters which are equivalent within the registry e (U+0065) = è (U+00E8) = é (U+00E9) = ê (U+00EA) = ë (U+00EB) Would my table need to be U+0065|U+00E8:U+00E9:U+00EA:U+00EB # LATIN SMALL LETTER E (e) which implies that everything after the | is an allowed character or do I have to explicitly take the first statement above into account where I need to put each character with its variants in a separate line therefore listing out all combinations i.e. U+0065|U+00E8:U+00E9:U+00EA:U+00EB # LATIN SMALL LETTER E (e) U+00E8|U+0065:U+00E9:U+00EA:U+00EB # LATIN SMALL LETTER E WITH GRAVE U+00E9|U+0065:U+00E8:U+00EA:U+00EB # LATIN SMALL LETTER E WITH ACUTE U+00EA|U+0065:U+00E8:U+00E9:U+00EB # LATIN SMALL LETTER E WITH CIRCUMFLEX U+00EB|U+0065:U+00E8:U+00E9:U+00EA # LATIN SMALL LETTER E WITH DIAERESIS If the second method is the correct way does the order then become important? Any help would be appreciated. Regards John John Hollifield GTLD Systems and Business Data Lead Nominet Tel: 01865 332333 Mob: 07979 696734 Email: John.Hollifield(a)nominet.org.uk<mailto:John.Hollifield@nominet.org.uk> John Hollifield GTLD Systems and Business Data Lead Nominet Tel: 01865 332333 Mob: 07979 696734 Email: John.Hollifield(a)nominet.org.uk<mailto:John.Hollifield@nominet.org.uk>

2 2

Escrow .REP Submission to ICANN test server issue
by Johnson, Scott Oct. 21, 2013

Oct. 21, 2013

All, When I attempt a submit to ICANN of my escrow report, I'm getting back http code which seems to indicate an authentication issue. According to ICANN, my credentials are accurate. Has anyone else had this issue? Am I missing something in my curl call? My Call: curl -H "Content-Type: text/xml" --request PUT --data @${REPFILE} --user *****:****** https://test-ry-api.icann.org:8543/report/registry-escrow-report/${gTLD}/${… Response: <html><head><title>Apache Tomcat/7.0.42 - Error report</title><style></style> </head><body><h1>HTTP Status 401 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>This request requires HTTP authentication.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.42</h3></body></html>etlpg@stdwpprdb1:/transfer/outbound/registry/neustar/icann/history> Thanks, Scott

1 0

URS Technical Requirements - version 20131017
by Gustavo Lozano Oct. 18, 2013

Oct. 18, 2013

Colleagues, Attached you will find the latest version of the URS technical requirements in clean and redline. This version incorporates the latest feedback from the list. For those new to this document, the objective is to define the technical requirements of the URS Procedures (latest version: http://newgtlds.icann.org/en/applicants/urs/procedure-01mar13-en.pdf) included in the AGB. The objective is to use the EPP RFCs as much as possible while trying to not impact the normal domain registration lifecycle. The procedures define email as the communication mechanism between URS providers and Registries/Registrars, therefore the URS technical requirements document defines email as the communication mechanism. If the volume of URS request grows high, the ICANN community may want to define a new mechanism (EPP, using an API, centralized operations, etc.) in the future and ICANN is willing to help in the effort. Regarding other policies that may be impacted by the URS and the leverage of Registries/Registrars to act on URS locked or URS suspended domain names, ICANN is always open to receive questions from Registries/Registrars and provide guidance. Based on the feedback from the list, we believe that this version could be publish as version 1.0, please let us know as soon as possible if you find any major roadblocks. We are planning to publish version 1.0 on Tuesday, 22/Oct/2013. Regards, Gustavo

2 2

Re: [gtld-tech] URS Technical Requirements - version 3
by Gould, James Oct. 10, 2013

Oct. 10, 2013

Kal, I have some follow on questions / comments to your feedback below. -- JG James Gould Principal Software Engineer jgould(a)verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 9/30/13 8:42 PM, "Kal Feher" <Kal.Feher(a)ariservices.com> wrote: >Gustavo, thank you for the updated document and your responses to my and >other's questions. > >I have a follow up question before I comment on the document. >I believe you may have misunderstood me when I asked about UDRP. I was >actually thinking about the scenario where a domain is URS'd first >(because it's a fast process) then, assuming the complainant is >successful, a UDRP is sought (because it is permanent). What are >Registrars and Registries supposed to do with UDRP results on domains >that are currently URS suspended? > > >-Regarding the document > >* Server lock will prevent the registrar from updating the domain in >response to normal circumstances, for example to remove Whois privacy >services as practised in UDRP cases, or to correct whois information >(e.g. mistyped phone number or mailing address). What leeway is given to >the registry operator to update registration information in response to >out of band requests by registrars attempting to meet their obligations >under other ICANN policies? > >* URS Suspension: Registries may not accept DS data, instead accept only >Key Data (RFC 5910). TThe URS provider should provide name server and >both key data and DS data, allowing the registry operator to insert the >relevant DNSSEC material into their provisioning systems. The URS lock will lock the domain and not the referenced contacts. The domain cannot be updated to reference a different contact, but the contact object can be updated since there is not a 1-to-1 relationship between the domain and the referenced contacts. Good question related to what leeway the registry has in making updates based on out-of-band (e.g. call to Customer Support) requests. You are correct that if the URS Provider does intend to DNSSEC enable the redirect on a URS Suspension, where the URS Provider should be prepared to provide both the DS and Key Data to support both models (DS Data Interface and Key Data Interface) defined in RFC 5910. > >*Registry Requirement 6: If the URS provider were to record whois at the >time of notifying the Registry for an action, the only notifications >required should be at deletion (c) and purged (d). All other information >regarding state change events is already available to the provider prior >to their occurrence. >Otherwise Registries are going to either have to modify their system's >workflow for URS'd domains (introducing software development costs and >risks) or maintain an offline list of to-do items for each domain in URS >suspension (introducing operational costs and risks). The expired and auto-renew notices is really collapsed into a single notice for auto-renew with registries that support auto-renew. I'm assuming that the main registry component that requires update is the auto renew component to delete the serverDeleteProhibited status, which I call URS Lock Expired or URS Suspension Expired. > >*Registry Requirement 10: Can you confirm that the option for the >complainant to add an additional year to the registration period of the >domain is not subject to the registration period being 12 months or less? >A simple renew with no caveats would be my preferred approach. My assumption is that the renew command at the registry level is unchanged. > >*Registrar Requirement 2 and Registry Requirement 11 appear not to align >with the other's purpose. I'd recommend removing Registry Requirement 11 >entirely. Registrars are already obligated to only accept the one extra >year (Rr requirement 3). Further applying systematic constraints (Ry Req >11) will simply prevent rectification of mistakes and will add to >complexity. Registrar Requirement 2 deals with URS Locked domains and Registry Requirement 11 deals with URS Suspended domains. The removal of the serverDeleteProhibited status at expiry / auto renew is consistent between URS Locked and URS Suspended domains. The support for restore is removed for URS Suspended domains only. Do you believe that URS Suspended domains should be able to be restored? > >-A comment on this approach > >I'm concerned that Registry system complexity is being added for what >should be a reasonably simple process. Some of this complexity seems to >be to relieve the URS provider of technical burdens (Requirement 6 and >the absence of EPP support by the URS provider) and applying those >burdens onto Registries. These changes will be costly for registries, >either in terms of development or labour and will introduce risks. As >things stand currently, to make these changes systematic, Registries will >have to add "(if domain_urs == true) then." logic throughout the >lifecycle for all domains, which is a concern for anyone interested in >stability. I'd like common sense to prevail and we simplify these >proposals significantly. Whilst the premise was circulated that making >the URS provider use EPP was unnecessarily costly without an >understanding of expected URS volumes, no such consideration has been >applied to the impact of modifying every Registry system to include what >is effectively a unique domain lifecycle. The only registry component that requires a systematic change is the auto renew component to remove the serverDeleteProhibited status at auto renew of URS Locked or URS Suspended domains. Handling of server statuses should already be supported by the registries. Much of the complexity comes from the PGP e-mail interface, which includes PGP e-mail verification of notices from the URS Provider, and generation of PGP signed e-mail to the URS Provider. > >I'd recommend removing the technical recommendations, proposing an >alternative and greatly simplified work-flow that is carried out without >lifecycle changes and committing to reviewing after N months/years based >on observed URS volumes. If an EPP (or like) interface is required. We >could write up a draft for EPP mapping of URS functions, which registries >could switch to within 180 days (Ry Agreement includes provisions for >this kind of service introduction). If the volume warrants the use of EPP, I would be interested in participating in the development of a standard EPP extension. > >Kal Feher >Enterprise Architect >ARI Registry Services > > > >From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On >Behalf Of Gustavo Lozano >Sent: Tuesday, 24 September 2013 10:52 AM >To: gtld-tech(a)icann.org >Subject: [gtld-tech] URS Technical Requirements - version 3 > >Colleagues, > >Attached you will find the third version of the URS technical >requirements and a redline of the previous version. This version includes >the feedback received on this list. We are planning to publish this >version as version 1.0 by late next week. > >If you believe there are specific issues that should be addressed on the >document, please send those specific issues to the list. > >The URS Technical Requirements document is a collection of technical >implementation guidelines of the URS Procedures that you will find at >http://newgtlds.icann.org/en/applicants/urs. > >Your feedback is appreciated. > >Regards, >Gustavo

3 3

URS Technical Requirements - version 3
by Gustavo Lozano Oct. 4, 2013

Oct. 4, 2013

Colleagues, Attached you will find the third version of the URS technical requirements and a redline of the previous version. This version includes the feedback received on this list. We are planning to publish this version as version 1.0 by late next week. If you believe there are specific issues that should be addressed on the document, please send those specific issues to the list. The URS Technical Requirements document is a collection of technical implementation guidelines of the URS Procedures that you will find at http://newgtlds.icann.org/en/applicants/urs. Your feedback is appreciated. Regards, Gustavo

2 2

Documentation on CZDAP
by Adrian Cho Oct. 2, 2013

Oct. 2, 2013

I have been looking about for documentation on the centralized zone data access provider. All I am able to find so far is the webinar from Durban so I was wondering if any of you kind folk can point me in the direction of the supporting documents. Regards Adrian

1 0

Q about ICANN Reporting, transfer related fields
by Alexander Mayrhofer Sept. 30, 2013

Sept. 30, 2013

Hi, there's a bit of ambiguity with some transfer-related fields in the ICANN reporting specifications. Since we're currently implementing the respective reports, some guidance would be appreciated: The description of the fields transfer-gaining-nacked transfer-losing-successfully transfer-losing-nacked leaves it open whether the datetime of the transfer request, or the datetime of the execution/rejection of the transfer shall be considered for identifying the reporting period, i.e. shall a transfer that is requested on March 30, and nacked on April 02 reported in March or April? Advice highly appreciated :-) thanks, Alex

1 0

Has anybody successfully uploaded LORDN data to test.ry.marksdb.org?
by Andreas Papst Sept. 27, 2013

Sept. 27, 2013

Hi, according to http://tools.ietf.org/html/draft-lozano-tmch-func-spec-07 I have tried both curl and wget to upload test-LORDN-files to https://test.ry.marksdb.org/LORDN/<TLD>/sunrise for example: curl -i -X POST -d @lordn.sunrise -u <username>:<password> https://test.ry.marksdb.org/LORDN/<GTLD>/sunrise where file lordn.sunrise contains test-data copied from draft-lozano-tmch-func-spec: 1,2013-09-26T02:15:00.0Z,1 roid,domain-name,SMD-id,registrar-id,registration-datetime,application-datetime 8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,2012-07-15T00:50:00.0Z the only answer returned is everytime: 400 - No file provided Any hint how this works? Best wishes Andreas -- ________________________________________________________________________ Andreas Papst | Vienna University Computer Center | E-Mail: andreas.papst(a)univie.ac.at Universitaetsstrasse 7 | Phone: +43 1 4277 / 140 36 A-1010 Vienna, Austria, Europe | Fax.: +43 1 4277 / 8 140 36

2 2

Using API to submit .REP file to ICANN
by Johnson, Scott Sept. 24, 2013

Sept. 24, 2013

Has anyone had success submitting the report using curl? Using the following: curl --request PUT --data @<filename.rep> --user <usename>:<password> <URL> I continue to get a result of: curl: (7) couldn't connect to host I have an account establish and I'm using the test url. --------------------------------------------------------------------------------- Scott Johnson Sr. Data Architect, Data Services Group NeuStar Inc. <mailto:scott.johnson@neustar.biz> 46000 Center Oaks Plaza, Cube 1137, Sterling, VA 20166-6596 Voice: 571-434-5496

2 1

URS technical requirements, comments and questions
by Gustavo Lozano Sept. 9, 2013

Sept. 9, 2013

Colleagues, The following is a list of comments/questions related to the second version of the URS technical requirements. Your feedback is appreciated. Comments from James Gould: 1. The text for requirement 8 provides two options for handling a domain that expires while in URS Lock that focuses on allowing the URS Lock domain to be deleted (online or offline) after the expiry and the subsequent auto renew. I believe that this is a corner case that adds some additional complexity. Allowing deletion of the URS Lock domain post-expiry makes the domain expiration date an element that must be considered when submitting the URS complaint. If the main driver of this requirement is to allow the domain to be deleted within the auto renew grace period, the likelihood of the URS process exceeding the auto renew grace period is extremely low. Based on my calculation the maximum URS duration is 45 days which matches our auto renew grace period of 45 days. The auto renew grace period of various TLD's could be shorter, but the auto renew grace period will most likely be a long enough period to cover the URS process. My recommendation is to not do anything at expiry of URS Lock domains and allow the URS process to complete prior to allowing the domain to be deleted. GL - For UDRP there is a provision (3.7.5.7) in the http://www.icann.org/en/resources/registrars/accreditation/eddp for handling the scenario of active UDRP process during the end of the validity period. Unfortunately the URS Procedures are silent about what happens if a URS locked DN expires. During our internal discussions, the conclusion was that the normal registration lifecycle should be followed when the URS Procedures are silent. The auto-renew grace period, as you mentioned may be shorter for some TLDs and this will create corner cases for the Registrars and the Registry Operator of that TLD, e.g. Is the registrar billed for the renew? Who pays the renew? Is credit provided to the Registrar if the URS process finalize and the registrant/complainant don't want the DN to be renewed? The number of UDRP cases filled in the last month of the validity period of a DN is low and we believe this is likely going to be the case for URS. The proposal is to show a warning message when filling the URS procedure if the domain name is within the last month of validity, explaining that the domain name may be deleted during the URS process and the process will be terminated. 2. The text in requirement 9 "Registry Operator MUST offer the option for the URS Complainant to extend a URS Suspended domain name registrations for up to one year from the date the domain name was Suspended", sounds like the renew command behavior needs to change for URS Suspension domains. The renew command should extend from the prior expiration date and not the date the domain name was suspended. I do not recommend making any change to the renew logic for URS Suspension domains, since it will impact all of the registries and the registrars. I recommend that the registries allow for the renew of URS Suspension domains and leave it up to the Registrars to ensure that the renew is done at most once for URS Suspension domains, by the URS Complainant, according to the Registry-Registrar Agreement. GL - The text needs to be clarified, as the idea behind Requirement 9 is basically what you are proposing. This is the proposed new text: Registry Requirement 9: In cases where a URS Complainant (as defined in the URS Rules) has prevailed, Registry Operator MUST offer the option for the URS Complainant to extend a URS Suspended domain name's registration (if allowed by the maximum validity period of the TLD). Registry Operator MAY collect the renewal fee paid by the URS Complainant for the URS Suspended domain name from the sponsoring Registrar of the domain name. It's worth mentioning that in section 4, the following provisions are defined: The Registry Operator MUST specify in the Registry-Registrar Agreement for the Registry Operator¹s TLD that the Registrar MUST accept and process payments for the renewal of a domain name by a URS Complainant in cases where the URS Complainant prevailed. The Registry Operator MUST specify in the Registry-Registrar Agreement for the Registry Operator¹s TLD that the Registrar MUST NOT renew a domain name to a URS Complainant who prevailed for longer than one year (if allowed by the maximum validity period of the TLD). 3. Handling the URS Suspension of domains when the domain has child hosts. The redirect of the domain with child hosts could impact many other domains outside that TLD, since the resolution of those name servers will not or should not work. If a registry shares the same pool of name servers across TLD's, the glue for the child hosts might be returned in DNS, but the resolvers might not trust cross-TLD name server glue. Consider the case of URS Suspension domain foo.com with child host ns1.foo.com, where bar.net uses ns1.foo.com as a name server. A query for bar.net could include the IP addresses for ns1.foo.com, but since .com and .net are different TLD's the resolver could and most likely independently attempt to resolve ns1.foo.com. Resolution of ns1.foo.com will not work if foo.com is redirected to the URS Provider's name servers. This issue impacts TLD's outside of that registry, since they most likely would not have the glue. There might be nothing that can be done about potentially breaking resolution of other domains using child name servers of a URS Suspension domain, but we should discuss it and determine if there is anything that needs to be done to minimize the impact. GL - It's difficult to know which domain names depend on another domain name as separate entities administer separate sections of the DNS tree. However, this seems to be a corner case. It would seem unlikely that URS suspended domain names will be used to define hosts of other domain names, as the expectation is that these domain names are not used for legitimate purposes, but we will work with URS providers to add some text that advises the Registrant of the URS suspended domain name that he/she should notify other Registrants which domain names may depend on the URS suspended domain name to take the appropriate action. 4. A related topic to #3 is what to do with the child hosts when a URS Suspension domain is auto-deleted / auto-purged at expiry. In our registries, a domain cannot be deleted if there are child hosts being used as name servers for other domains in our registry database. The registrars will typically rename the child hosts under another domain to allow for the domain to get deleted. My recommendation is to remove the serverDeleteProhibited status at expiry of a URS Suspension domain instead of auto-deleting or auto-purging it, and allow the domain to auto renew. The Registrar can and will most likely go ahead and delete the domain during the auto renew grace period following the existing process that they follow in deleting domains with child hosts being used as name servers for other domains. I recommend disallowing the use of the RGP restore command for URS Suspension domains that entered RGP after deletion. Without the ability to restore, the domain will propagate through the RGP statuses (redemptionPeriod and pendingDelete) prior to getting purged from the registry, which is consistent with how domains are currently deleted. GL - When creating the draft of the URS technical requirements, we followed the strategy that if something is not clear in the URS Procedures, we should follow the normal registration life cycle. Your suggestion follows this strategy; therefore we believe your proposal is adequate. The activation of serverUpdateProhibited during URS Lock and URS Suspension should be enough to prohibit the restore from working, therefore there is no need to specify that a Registrar should not send a restore command for URS suspended DNs or that the Registry should disallow restore, correct? Comments from Rubens Kuhl: As the second version still shows issues that the community addressed in the past for domain registrations, it seems to us that registries should handle URS providers the same ways they handle domain registrars: thru EPP. URS providers could have proper EPP credentials that would allow them to make a limited set of transformations (URS Suspension, URS Lock, URS Roll-back) to every domain in the registry (except for mandatory domains like NIC or WHOIS). Everything we are trying to do with e-mail have already been done with a higher degree of process integrity thru EPP. GL - The idea of using EPP has been discussed internally and was also mentioned during the conference call. Defining EPP extensions, requiring registries to modify their SRS implementations and requiring URS providers to implement EPP may be over engineering if we don't know the volume of URS procedures and the URS Procedures define email as the interaction mechanism. In case that the volume of URS procedures is high and the community believes that EPP support is required, ICANN is willing to consider transitioning the process to EPP. Comments from Kal Feher: Under what circumstances would a name transition from URS Suspension to URS Lock? I am referring to your Note under the definition of URS Lock. I¹ve reviewed both the technical and non-technical requirements and neither explain when this would occur. GL - This is an unlikely scenario, and the purpose of the note is that if this transition is required, the Registry Operator regenerates the glue records. Also will there be further detail on how URS interacts with other processes, such as UDRP? GL- Section 3(g) of the URS rules define: A URS Complaint may not be filed against a domain name that is part of an open and active URS or UDRP case. Regards, Gustavo

3 2

Re: [gtld-tech] URS technical requirements, comments and questions
by Luis Muñoz Sept. 7, 2013

Sept. 7, 2013

A related question to the list, On Sep 6, 2013, at 10:13 PM, Rob Golding wrote: >> 2. The text in requirement 9 "Registry Operator MUST offer the option >> for the URS Complainant to extend a URS Suspended domain name >> registrations for up to one year from the date the domain name was >> Suspended", sounds like the renew command behavior needs to change for >> URS Suspension domains > > Why ? Allowing them to renew (at the Registrar) if it _expires_ makes sense. > > Allowing it to be extended 174 days before expiry by 365 days ( 1 year ) > will break all sorts of things. In addition to this point, what is the practical purpose of this renewal? What is the purpose of prolonging the period during which a domain affected by URS is showing a "URS suspended" page? Specially if the subordinate host objects were removed or otherwise rendered inoperable. If the URS complainant effectively has rights to the domain in dispute, why not simply give her complete control of the domain in dispute? At that point the complainant can do as she pleases with the domain through regular channels, including dealing with subordinate objects. Best regards -lem

1 0

Re: [gtld-tech] URS technical requirements, comments and questions
by Mike O'Connor Sept. 7, 2013

Sept. 7, 2013

um… i admit it -- i haven't been following this too closely. but this thread looks like it's turning into a policy discussion rather than a "technical requirements" discussion. could somebody kinda bring me up to speed on the state of play of the underlying policies? sorry to be such a dolt. the PGP discussion fit in my expectations for what's supposed to happen on this list, but this seems a bit far afield. didn't most of these issues go through some kind of policy process already? thanks, mikey On Sep 6, 2013, at 9:13 PM, "Rob Golding" <rob.golding(a)astutium.com> wrote: >> The proposal is to show a warning message when filling the URS procedure >> if the domain name is within the last month of validity, explaining that >> the domain name may be deleted during the URS process and the process >> will be terminated. > > Certainly _if_ the domain is (actually) deleted (i.e. has gone through > expiry/redemption/whatever all the way to the final-actual-definate 'really > is' deletion, then yes, that should end the URS > >> 2. The text in requirement 9 "Registry Operator MUST offer the option >> for the URS Complainant to extend a URS Suspended domain name >> registrations for up to one year from the date the domain name was >> Suspended", sounds like the renew command behavior needs to change for >> URS Suspension domains > > Why ? Allowing them to renew (at the Registrar) if it _expires_ makes sense. > > Allowing it to be extended 174 days before expiry by 365 days ( 1 year ) > will break all sorts of things. > >> The renew command should extend from the prior >> expiration date and not the date the domain name was suspended > > Absolutely. > > However I don't agree that 'random-3rd-party' (URS complainant) shouldn't be > able to just 'renew' (extend) the registration of a domain name *unless* > it's expired/expiring. > > >> I recommend that the registries allow for the renew of URS Suspension >> domains and leave it up to the Registrars to ensure that the renew is >> done at most once for URS Suspension domains, by the URS Complainant, >> according to the Registry-Registrar Agreement. > > Having the registry reject any renewal for > 1 year (and for a 2nd time) on > a URS locked domain (with such restrictions to be removed when the URS lock > is removed) does make the most sense. > >> Registry Requirement 9: In cases where a URS Complainant (as defined in >> the URS Rules) has prevailed, Registry Operator MUST offer the option >> for the URS Complainant to extend a URS Suspended domain name's >> registration (if allowed by the maximum validity period of the TLD). > > No, not option by the *registry operator* given to the *urs complainant* > > Has to be the registrar renewing it ... wording is wrong. > > Can be written much simpler as > > == > Registry Requirement 9: > Registry Operator MUST allow REGISTRAR OF RECORD to extend the registration > of (renew) a URS Suspended Domain Name a maximum of one period whilst domain > is USR locked (if allowed by the maximum validity period of the TLD). > == > Then nothing else about who pays or who requests it etc is necessary. > >> Registry Operator MAY collect the renewal fee paid by the URS >> Complainant for the URS Suspended domain name from the sponsoring >> Registrar of the domain name. > > They wont if the renewal fee wasn't paid to the registrar ! > >> The Registry Operator MUST specify in the Registry-Registrar Agreement >> for the Registry Operator's TLD that the Registrar MUST accept and >> process payments for the renewal of a domain name by a URS Complainant >> in cases where the URS Complainant prevailed. > > There can be no "MUST" - we -like most countries - have restrictions on who > we can do business with. Similarly we always reserve the right to choose who > we do business with - you cannot enforce a MUST on the Registrar to take > money and/or process it from an "unknown entity" (the URS Complainant) - > people who we may not legally, logically, ethically, any-other-ally accept > money from or do business with. > > Similarly, anyone we take money from has to have agreed to our terms and > conditions, and if they haven't, we don't want their business or their money > - USR complainant or otherwise. > >> The Registry Operator MUST specify in the Registry-Registrar Agreement >> for the Registry Operator's TLD that the Registrar MUST NOT renew a >> domain name to a URS Complainant who prevailed for longer than one year >> (if allowed by the maximum validity period of the TLD). > > Is dealt with above. > >>> 3. Handling the URS Suspension of domains when the domain has child >>> hosts >> GL - It's difficult to know which domain names depend on another domain >> name as separate entities administer separate sections of the DNS tree. >> However, this seems to be a corner case > > It's be a criminal case if you redirected the child hosts or the responses > from nameservers. > > If foo.bar had ns1.foo.bar and blah.blah used ns1.foo.bar as a nameserver > Then on suspension and redirection of foo.bar there *MUST* be no record for > ns1.foo.bar so dns would "stop" > - anything else would be illegal > > I'm not sure there should even be any redirection of foo.bar itself going on > > >> URS providers could have proper EPP > > With the potential for them to screw up and the potential knock on 'damage' > and claims that would ensue, I'd rather not see any URS provider have access > to a computer, and make this all done on multi-part carbon-copy forms. > > Regards, > Rob > -- > rob.golding(a)astutium.com www.astutium.com 020 3475 2555 > Astutium Ltd, 1st Floor, Number One Poultry, London, EC2R 8JR > Registered in England (UK) / Company #8183381 / VAT #145054825 > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

2 1

Re: [gtld-tech] URS technical requirements, comments and questions
by Michele Neylon - Blacknight Sept. 7, 2013

Sept. 7, 2013

On 7 Sep 2013, at 02:19, Gustavo Lozano <gustavo.lozano(a)icann.org> wrote: > > > GL - The text needs to be clarified, as the idea behind Requirement 9 is basically what you are proposing. This is the proposed new text: > > Registry Requirement 9: In cases where a URS Complainant (as defined in the URS Rules) has prevailed, Registry Operator MUST offer the option for the URS Complainant to extend a URS Suspended domain name's registration (if allowed by the maximum validity period of the TLD). Registry Operator MAY collect the renewal fee paid by the URS Complainant for the URS Suspended domain name from the sponsoring Registrar of the domain name. That last sentence doesn't make any sense. Registry Operators do not collect the fees paid by anyone other than the registrar- they collect the fees they charge the registrar. Period. Registry X charges registrar $10 / year Registrar Y charges registrant (or in this case the URS complainant) their retail rate for the domain So if I want to charge $30 / year and Rob wants to charge $15 / year then that's our business model and not relevant to this policy. As long as we pay the registry for the renewal .. Put another way, there's no direct relationship between the Registry Operator and the URS Complainant. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation http://www.blacknight.co/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

2 1

URS, PGP or S/MIME
by Gustavo Lozano Sept. 6, 2013

Sept. 6, 2013

Colleagues, The second version of the URS High Level Technical Requirements defines S/MIME as the authentication and non-repudiation mechanism for the interaction between URS providers and Registries, and for the communication between URS providers and Registrars. Several emails to the list and private messages suggest that PGP should be used instead of S/MIME. We believe that either PGP or S/MIME could be used. The PGP solution that we envision would be like this: * ICANN gathers the valid PGP keys from Registries and URS providers. * ICANN maintains and publishes a keyring of URS providers PGP keys and a keyring of Registry Operators PGP keys. Each keyring would be signed with ICANN's PGP key and published on an HTTPS site. * Registry Operator/Registrar downloads the keyring of URS providers PGP keys frequently (every 12 hours appears to be appropriate considering the 24 hour windows to URS lock a DN and the potential revocation of a compromised key). * URS provider downloads the keyring of Registry Operators frequently. * ICANN provides a list of "TLD, PGP key id" to URS providers (we could use the comment field of the PGP key to identify the TLD(s), but a simple CSV file appears easier). The S/MIME solution that we envision would be like this: * ICANN provides a list of "TLD, authorized email address" to URS providers. * ICANN provides a list of "URS provider, authorized email address" to Registry Operators/Registrars. * Registry Operators and URS providers obtain certificates from public CAs (the list of well-known root CAs in different software products and libraries do the rest). ICANN can accommodate either the PGP or the S/MIME solution. However, we believe we should only do one to avoid unnecessary complication. The question is: * What is your preference? For version three of the URS technical requirements, we will define whatever the majority believes is the best approach. Regards, Gustavo

9 8

Second version of the URS High Level Technical Requirements for Registries and Registrars
by Gustavo Lozano Sept. 3, 2013

Sept. 3, 2013

Colleagues, Attached you will find the second version of the "URS High Level Technical Requirements for Registries and Registrars" and a redline version of the document. This second version incorporates the feedback obtained from the conference call on August 07. We appreciate your feedback. Please send your feedback to the list or in private. Based on the feedback in this list, a new conference call may be required or this version may be published as the final version. Registry Operators will know the name servers deployed by the URS providers soon, in order to allow Registry Operators to create host objects (if necessary). Thank you, Gustavo

6 7

RRI OT&E
by Gustavo Lozano Aug. 20, 2013

Aug. 20, 2013

Colleagues, ICANN has deployed an OT&E for the interfaces (Registry Reporting Interfaces) described in http://tools.ietf.org/html/draft-lozano-icann-registry-interfaces In order to access ICANN's RRI OT&E, the new gTLD Applicant (Primary Contact) needs to request access by submitting a case/request (a Back End Registry should only need one set of credentials) through the Customer Service portal (myicann.secure.force.com) The following information must be included in the case/request: * Subject line of ³Access Request for Registry Report Interface OT&E² * Application ID * IP addresses (up to five) that will be used to access the RRI OT&E. * An email address that will be added to ICANN¹s private RRI technical mailing list, direct interaction with ICANN's software development team is possible on this list. Version 02 of the draft will be published by the end of the week, it contains new result codes and minor updates. The production version of the RRI will be available after 5 weeks or less based on the results from your tests of the OT&E. The CSC (Customer Support Center) will start processing your requests on Wednesday (21/08/2013). Regards, Gustavo

2 2

URS-Technical Requirements conference call
by Gustavo Lozano Aug. 8, 2013

Aug. 8, 2013

Colleagues, In response to your requests, we are happy to schedule a teleconference to discuss feedback on the URS-Technical Requirements document sent on 8 July. The teleconference will focus on the attached document and questions or concerns you may have related to what is outlined in the requirements document. The proposed date and time for the conference call is Wednesday, August 7, 2013 from 20:00:00 to 22:00:00 UTC. Please login to: http://icann.adobeconnect.com/urs <http://icann.adobeconnect.com/tmch> The requirements for URS are detailed in the AGB pp. 299 to 309. The proposed topics for discussion are: Communication mechanisms between Registries and URS providers. PGP or S/MIME to sign emails?. Implementing the URS lock. Domain name life cycle of URS locked and suspended domain names. How the URS lock affects the "normal" business processes of Registrars. Interaction between Registries and Registrars. Is EPP support required? Redirection and storing the current state of the domain name for the rollback. If you feel that other topics should be addressed during the conference call please propose them and I will add them to the list of topics. If you want to send alternative proposals that comply with the requirements in the AGB, feel free to send those to the list and we can discuss them during the conference call. Regards, Gustavo

2 1

Test SMDs files now available
by Gustavo Lozano Aug. 7, 2013

Aug. 7, 2013

Colleagues, Information about the recently published test SMDs files can be found in the following link: http://newgtlds.icann.org/en/about/trademark-clearinghouse/smd-test-reposito ry-15jul13-en.pdf The different parties involved in the TMCH project have developed test SMDs files in order to obtain feedback from the community and assist implementers of the SMD technology in testing their own implementations. These test SMDs files have been generated using the same models of HSMs (ICANN-TMCH-CA and TMV) that are going to be used in production. The code used to generate them is the latest version of the TMCH code developed by the different parties involved in the TMCH project. These test SMDs files should cover the different test cases and comply with http://tools.ietf.org/html/draft-lozano-tmch-smd-02 We appreciate your feedback no later than July 23, please test them and send your feedback to the mailing list or to me privately. We understand that this is a short period of time and any bug found after this date will be corrected, but it is extremely helpful if you could send your feedback before this date. Note: These test SMDs files include the TMV and CA certificate embedded in the XML, new test SMDs files are going to be generated soon in order to remove the CA certificate. The inclusion of the CA certificate in the SMD file should not have an impact on the tests performed with these SMDs files. Thank you, Gustavo

10 18

gtld-tech URS technical requeriments
by Gustavo Lozano July 29, 2013

July 29, 2013

Colleagues, Attached you will find a draft version of the URS technical requirements. You can find more information of how URS works here: http://newgtlds.icann.org/en/applicants/urs/rules-28jun13-en.pdf The AGB provides high-level requirements regarding the URS procedures; the objective of the attached document is to define the detailed technical requirements for Registries and Registrars. Another document with the technical requirements for the URS provider is going to be published soon, but right now we want to obtain feedback regarding the requirements for Registries and Registrars. Please provide your feedback no later than Tuesday 23 of July. If you are going to be in Durban, send me an email and we can arrange an informal discussion about this. Regards, Gustavo

19 30

Re: [gtld-tech] gtld-tech URS technical requeriments
by Michele Neylon - Blacknight July 9, 2013

July 9, 2013

Jeff As a registrar all I really want to know is: - what if any obligations I have ie. your "what" - if those obligations are technically and commercially feasible I'm going to have to read over the other documents that were linked to, but forcing parties into contracts with each other seems odd (ie. the renewal obligation thing) regards Michele On 9 Jul 2013, at 14:07, "Neuman, Jeff" <Jeff.Neuman(a)neustar.us> wrote: > I guess my point in this is that we should be concerned with the "what" are registries and registrars supposed to do as opposed to the "how". And from my re-reading of the AGB, it seems like that document for the most part does an ok job in that. > > ICANN should not be mandating that any of this be done in an automated fashion, nor should it mandate things like "all e-mails sent by Registry Operator to the URD Provider MUST be cryptographically signed using a S/MIME certificate....." > > The whole thing just seems unnecessarily prescriptive to me. Frankly I would rather ICANN be spending its time worrying about getting up the testing environment with the TMCH than with this, but that may just be me. > > > > > Jeffrey J. Neuman > Neustar, Inc. / Vice President, Business Affairs > > > -----Original Message----- > From: James Mitchell [mailto:james.mitchell@ausregistry.com.au] > Sent: Monday, July 08, 2013 11:15 PM > To: Neuman, Jeff; Mike O'Connor > Cc: John R.Levine; gtld-tech(a)icann.org > Subject: RE: [gtld-tech] gtld-tech URS technical requeriments > > Do we need this? Yes. > > A standard/specification is required if there is to be a consistent implementation across all registries. Seeking an update on URS technical/process issues was on our agenda for Durban - instead we can now discuss moving this forward (in whatever direction that may be). Thanks to Gustavo for getting this document out, and the discussion rolling. > > Regards, > James Mitchell / Product Owner > ARI Registry Services > >> -----Original Message----- >> From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] >> On Behalf Of Neuman, Jeff >> Sent: Tuesday, 9 July 2013 11:07 AM >> To: Mike O'Connor >> Cc: John R.Levine; gtld-tech(a)icann.org >> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments >> >> With all due respect, most of the registries that have been planning >> on actually launching at some point this year I would venture to say >> have either already built their functionality to do this or are >> otherwise planning to do this manually, both of which are acceptable >> options. We have pretty much known the rules now from the Guidebook >> for months - dare I say years for this. >> >> I am not sure who asked for a "standard" to be developed on this, but >> this is WAY too late in the game for icann to expect any registry to >> move to this new "standard" at this point in time. >> >> So I will ask the dumb question again...do we really need this? >> >> My question >> >> Sent from my iPad >> >> On Jul 8, 2013, at 7:42 PM, "Mike O'Connor" <mike(a)haven2.com> wrote: >> >>> hi all, >>> >>> a few questions: >>> >>> - is this really a "technical specification" or is it really a >>> higher >> level document (maybe something along the lines of a functional >> requirements definition)? if i were a coder looking for a technical >> spec, i'd be sending this back with a little note saying "try again." >> is a technical spec to follow? or is it up to the >> registries/registrars to implement these capabilities within their own >> architecture? >>> >>> - when does all the implementation (across registries and >>> registrars) >> need to be complete? is there a testing cycle to see whether things >> work as expected? who leads that? what happens if it's not done on >> time or doesn't work right? >>> >>> - is it expected that registries store the prior state of NS and DS >> records when a URS provider makes a request (i'll leave it up to >> Levine as to how they do it)? if the registries don't store that data >> (presumably using new code), how can they fulfill the requirements >> that prior data be restored in various use cases? if they do store >> it, who has access to that data? how does domain-name lifecycle >> information from registrars find its way into the stored data so that >> if the domain is restored, it's restored to the current (rather than >> the stored) state? >>> >>> if this isn't due to roll out for a year, i think we've got time to >> react. if it's supposed to roll out in a few months, life's going to >> get interesting. >>> >>> mikey >>> >>> >>> On Jul 8, 2013, at 5:39 PM, John R. Levine <johnl(a)iecc.com> wrote: >>> >>>>> Let me ask the dumb question....do we really need a set of >>>>> standard >> specs for this for a registry? >>>> >>>> If URS exists at all (a battle that appears to have been lost quite >> a while ago) I would have to say yes, since if people roll their own, >> they'll likely make all the same security mistakes this spec does, and >> more. >>>> >>>> The basic problem is that the Internet is not synonymous with web >> servers, but too many people forget that. >>>> >>>> R's, >>>> John >>>> >>>>> ----- Original Message ----- >>>>> From: John R. Levine [mailto:johnl@iecc.com] >>>>> Sent: Monday, July 08, 2013 06:29 PM >>>>> To: Gustavo Lozano <gustavo.lozano(a)icann.org> >>>>> Cc: gtld-tech(a)icann.org <gtld-tech(a)icann.org> >>>>> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments >>>>> >>>>>> Please provide your feedback no later than Tuesday 23 of July. >>>>> >>>>> Thanks for publishing this. >>>>> >>>>> Unfortunately, the "URS Lock with Redirection" spec is a security >> disaster >>>>> for e-mail, pariticularly since, as I understand it, a typical use >> for the >>>>> URS will be to deal with typosquats of famous names such as >> páypàl.tld. >>>>> >>>>> Do we just send comments to you or is there a more formal place? >>>>> I expect that several anti-abuse organizations will want to weigh in. >>>>> >>>>> R's, >>>>> John >>>> >>>> Regards, >>>> John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet >> for Dummies", >>>> Please consider the environment before reading this e-mail. >> http://jl.ly >>> >>> >>> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: >> OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) >>> Mr Michele Neylon Blacknight Solutions ♞ Hosting & Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

3 2

Re: [gtld-tech] URS technical requeriments
by Michele Neylon - Blacknight July 9, 2013

July 9, 2013

Gustavo Just some initial thoughts .. Section 4: "Registrar MUST handle payments .. " Sorry, but I don't see how that's going to work The complainant has to enter into a contractual agreement with us as a registrar before we will accept payments from them ie. accept our terms and conditions etc., And the complainant may wish to move the domain to their preferred registrar etc., Also I can see plenty of obligations on registries and several on registrars, but will the URS provider actually inform us, as a registrar, of domains subject to URS? Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ________________________________ From: gtld-tech-bounces(a)icann.org [gtld-tech-bounces(a)icann.org] on behalf of Gustavo Lozano [gustavo.lozano(a)icann.org] Sent: 08 July 2013 23:01 To: gtld-tech(a)icann.org Subject: gtld-tech URS technical requeriments Colleagues, Attached you will find a draft version of the URS technical requirements. You can find more information of how URS works here: http://newgtlds.icann.org/en/applicants/urs/rules-28jun13-en.pdf The AGB provides high-level requirements regarding the URS procedures; the objective of the attached document is to define the detailed technical requirements for Registries and Registrars. Another document with the technical requirements for the URS provider is going to be published soon, but right now we want to obtain feedback regarding the requirements for Registries and Registrars. Please provide your feedback no later than Tuesday 23 of July. If you are going to be in Durban, send me an email and we can arrange an informal discussion about this. Regards, Gustavo

2 1

gtld-tech Final Draft Agenda for TechDay Durban 2013-07-15
by Dr Eberhard W Lisse July 8, 2013

July 8, 2013

Hi, herewith the final draft agenda. greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

gtld-tech Final Draft Agenda for TechDay Durban 2013-07-15
by Dr Eberhard W Lisse July 8, 2013

July 8, 2013

Hi, herewith the final draft agenda. greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

gtld-tech Clarifications to the registry monthly transactions report for new gTLDs
by Francisco Arias July 3, 2013

July 3, 2013

Colleagues, I've attached a draft of the updated section of Specification 3 for the new gTLDs related to the registry monthly transactions report. The attached file contains clarifications on what each of the fields mean. We are looking to see if the new proposed text makes clearer the intent on each field. We are not looking to change the meaning. Your kind and timely review would be greatly appreciated by this Thursday, 27 June at 15:00 UTC. Apologies for the short notice. Regards, -- Francisco.

4 6

gtld-tech New version of draft-lozano-icann-registry-interfaces
by Gustavo Lozano June 27, 2013

June 27, 2013

Colleagues, Version 01 of draft-lozano-icann-registry-interfaces has been published. This document describes the interfaces provided by ICANN to Registry Operators in order to fulfill the requirements of Specification 2 and 3 of the New gTLD Base Agreement. The interface provided by ICANN to Data Escrow Agents in order to fulfill the requirements of Specification 2 of the New gTLD Base Agreement is also described in this document. This version incorporates feedback from escrow agents and registry operators. I appreciate your feedback. ICANN will provide a testing environment for all the interfaces described in the draft soon. Regards, Gustavo

1 0

gtld-tech Call for Presentations for TechDay at ICANN Durban
by Dr Eberhard Lisse June 26, 2013

June 26, 2013

As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Durban. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz This time we would like to have an African focus, if possible, hence African presenters are strongly encouraged to come forward. As we have no budget presenters are responsible for their own transport and room and board. As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

3 4