March 2019 - gtld-tech - lists.icann.org

TMCH Test-SMDs expired...
by Alexander Mayrhofer Oct. 24, 2022

Oct. 24, 2022

Hello everyone, the test SMD-Files provided by the TMCH have expired yesterday (see below). Our unit testing infrastructure obviously fails on these tests currently, because it requires/assumes the SMD files to be valid. Are there updated test files available yet? If not, when will they be provided? best, Alex SMDs from http://newgtlds.icann.org/en/about/trademark-clearinghouse/smd-active-15jul… $ grep notAfter *.smd Court-Agent-Arabic-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Agent-Chinese-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Agent-English-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Agent-French-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Agent-Russian-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Holder-Arabic-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Holder-Chinese-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Holder-English-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Holder-French-Active.smd:notAfter: 2017-07-10 00:00:00 Court-Holder-Russian-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Agent-Arabic-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Agent-Chinese-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Agent-English-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Agent-French-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Agent-Russian-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Holder-Arabic-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Holder-Chinese-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Holder-English-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Holder-French-Active.smd:notAfter: 2017-07-10 00:00:00 Trademark-Holder-Russian-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Agent-Arabic-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Agent-Chinese-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Agent-English-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Agent-French-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Agent-Russian-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Holder-Arabic-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Holder-Chinese-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Holder-English-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Holder-French-Active.smd:notAfter: 2017-07-10 00:00:00 TreatyStatute-Holder-Russian-Active.smd:notAfter: 2017-07-10 00:00:00

6 20

RDAP zoneSigned flag
by Michael Bauland March 28, 2019

March 28, 2019

Hi, I just stumbled across the definition of zoneSigned as part of the secureDNS member in RFC7483. There is says: zoneSigned -- true if the zone has been signed, false otherwise. Now I'm wondering whether this relates to the TLD zone (i.e., it always MUST be set to true for ngTLDs) or whether the SLD zone is meant, in which case the registry does not know the value and simply won't publish it. Thanks in advance, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland(a)knipp.de Software Development E-mail: Michael.Bauland(a)knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp

2 3

FW: Call for Registration & Proposals - ROW#8 - Bangkok
by Hollenbeck, Scott March 27, 2019

March 27, 2019

FYI, folks. Sorry for the cross-posting. Scott From: Nicoleta Munteanu <munteanu.nicoleta(a)outlook.com> Sent: Wednesday, March 27, 2019 1:42 AM Subject: [EXTERNAL] Call for Registration & Proposals - ROW#8 - Bangkok Register now for the 8th Registration Operations Workshop! | May 9th, 2019 | Bangkok, Thailand The 8th Registration Operations Workshop<http://regiops.net/> (ROW#8) is scheduled to take place on Thursday, 9 May 2019, afternoon, in Bangkok, Thailand, during the last day of the GDD Industry Summit<https://www.icann.org/gddsummit> (6-9 May) and within the same venue. The workshop will also be collocated with ICANN DNS Symposium<https://www.icann.org/ids> (10-11 May) and OARC 30<https://indico.dns-oarc.net/event/31/> (12-13 May). Registration process is now available at: http://regiops.net/?event=8th-registration-operations-workshop-row8 Please note that the call for presentation and panel proposals is still active. In keeping with the Registration Operations' focus of the ROW, possible topics for this session could be: * RDAP implementation experience (presentations and/or panel of implementors to discuss their experience) * Registry Lock / Security Lock (presentations and/or panel of operators to discuss approach, experience, challenges) * Operation (Performance) Statistics Related to Registration * Data Escrow * Suggestions for additional topics Proposals in the form of a short abstract shall be submitted to row(a)viagenie.ca<mailto:row@viagenie.ca>. Deadline is April 2nd, 2019. Discussions of workshop topics may also take place on the regiops(a)googlegroups.com<mailto:regiops@googlegroups.com> mailing list. We hope that you can join us and request that you disseminate this Call to other lists where it might be of interest. Visit http://regiops.net for additional event details, more information on the venue, and previous ROW events. We look forward to seeing you in Bangkok! ROW Program Committee Stay tuned for further updates! Follow us on Twitter @ROW_by_Viagenie<https://twitter.com/ROW_by_Viagenie> ROW website: http://regiops.net<http://regiops.net/> Contact us: row(a)viagenie.ca<mailto:row@viagenie.ca> ROW mailing list: regiops(a)googlegroups.com<mailto:regiops@googlegroups.com> (sign-up at: https://groups.google.com/forum/#!forum/regiops/join) (cross-posting to multiple lists - sorry for any duplicates)

1 0

Technical Study Group Publishes Draft Model for Review and Input
by Francisco Arias March 8, 2019

March 8, 2019

FYI On 3/8/19, 3:42 PM, "TSG-Access-RD on behalf of Diana Middleton" <tsg-access-rd-bounces(a)icann.org<mailto:tsg-access-rd-bounces@icann.org> on behalf of diana.middleton(a)icann.org<mailto:diana.middleton@icann.org>> wrote: Dear all, the most recent blog on our progress was published: https://www.icann.org/news/blog/technical-study-group-publishes-draft-model… Best, Diana

1 0

Re: [gtld-tech] [Ext] AW: RDAP service in the gTLD space
by Francisco Arias March 4, 2019

March 4, 2019

Hi Alex, We are planning to release the update by May. -- Francisco On 2/27/19, 11:14 PM, "Alexander Mayrhofer" <alexander.mayrhofer(a)nic.at<mailto:alexander.mayrhofer@nic.at>> wrote: Francisco, can you give us a timeline for the potential extension of the “Registrar ID” registry at IANA (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml)? – I understand that the RDAP base URL is to be added there, so that registries don’t need to collect that information from registrars individually. Since we’d like to test that rather soon, it would be appreciated if that extension happened rather sooner than later. Best, Alex Von: gtld-tech <gtld-tech-bounces(a)icann.org> Im Auftrag von Francisco Arias Gesendet: Donnerstag, 28. Februar 2019 00:34 An: gtld-tech(a)icann.org Betreff: [gtld-tech] FYI: RDAP service in the gTLD space Today, ICANN org issued a notification to gTLD registries and registrars of the requirement to implement an RDAP service by 26 August 2019. https://www.icann.org/resources/pages/rdap-implementers-resources-2018-08-3… -- Francisco

1 0

Hopefully Final Agenda for TechDay Kobe ICANN64
by Dr Eberhard W Lisse March 4, 2019

March 4, 2019

Plnce ease find enclosed, the agenda will also be published by the ccNSO Secretatriat on the web site and in the Google Calendar for ease of planning. 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] [regext] EPDP recommendations and EPP
by Roger D Carney March 1, 2019

March 1, 2019

Good Morning, Thanks for the comments Patrick. Agreed, another one of the concerns going with placeholders is that to some, it will lessen the urgency to solve the underlying issue. Not speaking specifically to the examples you gave on multiple mechanisms, I still believe that adding an additional contact mapping will increase implementation complexity that is not needed, more below. As far as tailoring the protocol, it seems to me that the current RFC 5733 has been tailored. I am not sure why 5733 required these fields to exist in the first place, I assume it was discussed when it was written many years ago and it was decided for some reason these fields be treated special, but I don't see a technical reason to treat them differently. I don't think the idea of making the EPP Contact Mapping more flexible is a gTLD specific solution. Thanks for digging deeper into what it takes to "improve" the current mechanism. As Gavin mentioned in his original email, this would require a new RFC be created and you have provided some more logistics to that effort. As you mention, there may be clients that may need to support both namespaces, but for servers that choose to use the new namespace the interface on both sides would be less complex than having two mapping mechanisms. Servers could have the option of supporting the namespace that is appropriate for them (though I assume for gTLDs ICANN would update policy to use the new namespace). Thanks Roger -----Original Message----- From: regext <regext-bounces(a)ietf.org> On Behalf Of Patrick Mevzek Sent: Friday, March 1, 2019 9:55 AM To: regext(a)ietf.org Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP On Fri, Mar 1, 2019, at 16:22, Roger D Carney wrote: > Thanks for the comments Patrick. I agree about the pollution of > placeholders and that is one reason why I think it can only be used as > a temporary solution. If this is implemented, it will become permanent and there will be nothing else replacing it later. > I am not sold on creating a "new object." Another way to do the same > intention, to me this will just get convoluted for implementers (look > here unless you should look over there). I do not feel that convoluted and even if it is the case we already have many of them: - host attributes vs host objects - secDNS keyData vs dsData etc. > To me this is just creating a > new mechanism to avoid fixing a problem in the current mechanism. There is no problem in current mechanism. ccTLDs are all "fine" with it. Right now we are discussing (in multiple places so that makes participating difficult) things that will only apply to gTLDs. I really do not want again to give everyone's impression that we are tailoring a protocol to a very specific case just because the major vocal interests are there. In short, if gTLDs need another contact model because the one in RFC5733 is not fitting today anymore, it seems the clearer and simpler to me to just define a new model for contacts. > I am not sure how improving RFC 5733 to be more flexible and data > privacy/protection aware is a detriment to anyone using EPP. Anyone > using 5733 needs to be acutely aware of data "processing" and would > greatly benefit from a more flexible technical solution. You can not "improve" RFC 5733. You will need to create a new namespace, like "contact-2.0" At which point it is quite the same for implementors because any client with multi registries need will need to handle both namespaces (you can not expect all registries, specially non gTLD ones, just moving to your new schema, even if it is a strict superset of previous ones, because they will have absolutely 0 reasons, technical or economical, to do the change), so if you have "contact-1.0" and "contact-2.0" namespaces to handle OR "contact-1.0" and "lightContact-1.0" (or "shallowContact-1.0" or "gtldContact-1.0" or whatever) it is basically the same amount of work, but second option seems better to me for multiple reasons. And again, there is a huge non technical difference. If we give again the impression to change the EPP just to suite gTLD needs, we should not lament later on the state of EPP worldwide and why not everyone follows the standard to the letter, or best current practices, etc. -- Patrick Mevzek pm(a)dotandco.com _______________________________________________ regext mailing list regext(a)ietf.org https://www.ietf.org/mailman/listinfo/regext

1 0

Re: [gtld-tech] [regext] EPDP recommendations and EPP
by Roger D Carney March 1, 2019

March 1, 2019

Good Morning, Thanks for the comments Patrick. I agree about the pollution of placeholders and that is one reason why I think it can only be used as a temporary solution. I am not sold on creating a "new object." Another way to do the same intention, to me this will just get convoluted for implementers (look here unless you should look over there). To me this is just creating a new mechanism to avoid fixing a problem in the current mechanism. I am not sure how improving RFC 5733 to be more flexible and data privacy/protection aware is a detriment to anyone using EPP. Anyone using 5733 needs to be acutely aware of data "processing" and would greatly benefit from a more flexible technical solution. Thanks Roger -----Original Message----- From: regext <regext-bounces(a)ietf.org> On Behalf Of Patrick Mevzek Sent: Friday, March 1, 2019 9:03 AM To: regext(a)ietf.org Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP On Fri, Mar 1, 2019, at 15:39, Roger D Carney wrote: > I think I am in agreement with most people on this, that option 3 (or > C, whatever it is called) is the best short term solution “define a > "convention" that allows the <city> and <cc> elements to contain > placeholder values, such as: <city>-</city> and <cc>XX</cc> which pose > no data protection issues”. I am completely againts such placeholders. While they are the easy fast solution, they just pollute databases with useless data. Instead of updating RFC5733 I would suggest creating a new object, a "light (or shallow) contact" which is like a contact currently, just with less fields. Domains could use "full contacts" (the ones we know today) or light contacts (the new ones). One has to keep remembering that EPP is not just used by gTLDs, so any change has to be done in such a way that it does not impact negatively any operation done outside of ICANN circles. -- Patrick Mevzek pm(a)dotandco.com _______________________________________________ regext mailing list regext(a)ietf.org https://www.ietf.org/mailman/listinfo/regext

1 0

EPDP recommendations and EPP
by Gavin Brown March 1, 2019

March 1, 2019

Hi all, The EPDP final report says that, if a domain name has a technical contact (whose information is different from the registrant's), the only data that registrars should send to registries are the technical contact's name, email address, and phone number (if any). Assuming that technical contacts should still be created and managed as RFC 5733 contact objects, and also assuming that this recommendation is adopted without change, it poses a challenge, because the RFC requires all contact objects to have <city> and <cc> elements. I've been thinking about how this could be resolved, here are some ideas (in descending order of nastiness): * write a new RFC which updates RFC 5733 to make the <city> and <cc> elements optional * write a new EPP extension which makes the technical contact's name, email address, and phone number directly attributes of the the domain name rather than a contact object * define a "convention" that allows the <city> and <cc> elements to contain placeholder values, such as: <city>-</city> and <cc>XX</cc> which pose no data protection issues. Any thoughts? -- 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/ +44.7548243029 CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

6 9