- gtld-tech - lists.icann.org

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