- gtld-tech - lists.icann.org

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

FYI: RDAP service in the gTLD space
by Francisco Arias Feb. 28, 2019

Feb. 28, 2019

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

2 1

Call for Presentations ICANN64 Kobe
by Dr Eberhard W Lisse Feb. 21, 2019

Feb. 21, 2019

Draft Call for Presentations 39th TechDay at ICANN 64 in Kobe The ICANN Tech Working Group is again planning a technical workshop at the ICANN 64 meeting in Kobe on Monday 2019-03-11 The TechDay workshop has been a part of ICANN meetings since 2006 and has provided a forum for both experienced and new people to meet, present and discuss technical topics related to registry and DNS work and security. We are specially interested in: 1. Planning for the Worst We all know classic advice to have off-site backup or secondary datac enters. What measure can be taken to lessen the impact when disaster hits? Is it fine to let the registration system fail, while you concentrate on keeping DNS service alive? But what about when disaster does not hit you, but affects registrants somewhere else in the world? Do you extend the registration period, to prevent domains from expiring while they recover? We are interested in presentations on how registries prepare themselves for disaster, and especially encourage registries, that were struck by disaster, to share their experiences. 2. Universal Acceptance We are quite interested in presentations regarding the above and/or related to IDN. 3. In addition, we welcome suggestions for additional topics, such as; * DNS over TCP, DNS over HTTPS If you are interested in presenting, please email ccNSO-techday(a)icann.org We hope that you can join us and request that you disseminate this Request to other lists where it might of interest. --------------------------cut-here---------------------- -- Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 / Bachbrecht, Namibia ;____/

1 1

FW: Call for proposals - ROW#8 - Bangkok
by Hollenbeck, Scott Feb. 15, 2019

Feb. 15, 2019

Forwarding for your info… Scott From: Nicoleta Munteanu <munteanu.nicoleta(a)outlook.com> Sent: Friday, February 15, 2019 12:06 AM Subject: [EXTERNAL] Call for proposals - ROW#8 - Bangkok Call for presentation and panel proposals for the 8th Registration Operations Workshop (ROW#8) | May 9th, 2019 | Bangkok, Thailand The 8th Registration Operations Workshop<http://regiops.net/> (ROW#8) is scheduled to take place on the afternoon of Thursday, 9 May 2019, in Bangkok, Thailand. The workshop will take place immediately after ICANN’s GDD Industry Summit<https://www.icann.org/gddsummit> and prior to ICANN DNS Symposium<https://www.icann.org/ids> and OARC 30<https://indico.dns-oarc.net/event/31/>. For the past 5 years, ROW has provided a forum for all industry members, including address registries, domain name registrars, gTLD registries, ccTLD registry operators, resellers, and second level domain registries, to present and discuss technical topics related to real world experiences of implementing registration operations. In the past, workshops have included presentations and discussions focused on the Extensible Provisioning Protocol (EPP), WHOIS, and the Registration Data Access Protocol (RDAP). Any technical topic associated with registration operations is “in scope”. The Program Committee is now opening a call for presentation and panel proposals and is interested in: 1. Topic related presentation proposals. 2. Topic suggestions for focused panel discussions. 3. Suggestions for additional topics. Please email an abstract describing your proposal to row(a)viagenie.ca<mailto:row@viagenie.ca>. 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

Call for Participation -- ICANN DNSSEC Workshop at ICANN64 Kobe, Japan
by Jacques Latour Jan. 16, 2019

Jan. 16, 2019

Call for Participation -- ICANN DNSSEC Workshop at ICANN64 Kobe, Japan The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN64 meeting held from 09-14 March 2019 in Kobe, Japan. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Annual General Meeting in Barcelona, Spain, on 24 October 2018. The presentations and transcripts are available at: https://63.schedule.icann.org/meetings/901549, and https://63.schedule.icann.org/meetings/901554, and https://63.schedule.icann.org/meetings/901555. At ICANN64 we are particularly interested in live demonstrations of uses of DNSSEC, DS automation or DANE. Examples might include: * DNSSEC automation and deployment using CDS, CDNSKEY, and CSYNC * DNSSEC/DANE validation in browsers and in applications * Secure email / email encryption using DNSSEC, OPENPGPKEY, or S/MIME * DNSSEC signing solutions and innovation (monitoring, managing, validation) * Tools for automating the generation of DNSSEC/DANE records * Extending DNSSEC/DANE with authentication, SSH, XMPP, SMTP, S/MIME or PGP/GPG and other protocols Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet. We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include: 1. DNSSEC Panel (Regional and Global) For this panel, we are seeking participation from those who have been involved in DNSSEC deployment in the region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. DS Automation We are looking at innovative ways to automate the parent child synchronization CDS / CDNSKEY and methods to bootstrap new or existing domains. We are also interested in development or plans related to CSYNC, which are aimed at keeping the glue up to date. We would like to hear from DNS Operators what their current thoughts on CDS/CDNSKEY automation are. 3. DNSSEC/DANE Support in the browsers We would be interested in hearing from browser develop what their plans are in terms of supporting DNSSEC/DANE validation. 4. DANE Automation For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet? * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries? * What tools and services are now available that can support DANE usage? We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-kobe(a)isoc.org' before ** 07 February 2019 ** We hope that you can join us. Thank you, Jacques Latour On behalf of the DNSSEC Workshop Program Committee: Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Russ Mundy, Parsons Ondřej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society Mark Elkins, DNS/ZACR

1 0

FW: ROW#8 - May 9th, 2019 - Bangkok, Thailand
by Hollenbeck, Scott Nov. 4, 2018

Nov. 4, 2018

FYI, folks! Scott From: regiops(a)googlegroups.com <regiops(a)googlegroups.com> On Behalf Of Nicoleta Munteanu Sent: Thursday, November 01, 2018 6:41 PM Subject: [EXTERNAL] [regiops] ROW#8 - May 9th, 2019 - Bangkok, Thailand 8th Registration Operations Workshop (ROW#8) | May 9th, 2019 | Bangkok, Thailand The ROW Program Committee is pleased to invite you to save the date for our 8th Registration Operations Workshop<http://regiops.net/> (ROW#8), scheduled to take place on the afternoon of Thursday, 9 May 2019, in Bangkok, Thailand at the Shangri-La<http://www.shangri-la.com/bangkok/shangrila/> hotel. The workshop will take place immediately after ICANN’s Global Domains Division (GDD) Industry Summit and prior to ICANN’s Domain Name System (DNS) Symposium, and the DNS Operations, Analysis, and Research Center (DNS-OARC). The events will take place at the same venue, as follows: •• GDD Industry Summit<https://www.icann.org/gddsummit>: Monday, 6 May – Thursday, 9 May 2019 •• ROW#8<http://regiops.net>: Thursday, 9 May 2019, afternoon •• ICANN DNS Symposium<https://www.icann.org/ids>: Friday, 10 May – Saturday, 11 May 2019 •• DNS OARC<https://indico.dns-oarc.net/event/29/>: Sunday, 12 May – Monday, 13 May 2019 The workshop is a half-day event focused on, but not be limited to, technical aspects of real world experiences of implementing registration operations for the Registration Data Access Protocol (RDAP) pilot and gTLD launches. Given the current positioning of the ROW, the Program Committee is welcoming any suggestions for the ROW#8 theme, discussion/presentation proposals or comments regarding a change in the format of the session to allow for a goal oriented workshops incorporating deliverables, decisions or proposed solutions to be adopted. Discussions may take place on the regiops(a)googlegroups.com<mailto:regiops@googlegroups.com> mailing list or by email at row(a)viagenie.ca<mailto:row@viagenie.ca>. 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) Add us to your calendar: (cross-posting to multiple lists - sorry for any duplicates) -- You received this message because you are subscribed to the Google Groups "Regiops" group. To unsubscribe from this group and stop receiving emails from it, send an email to regiops+unsubscribe(a)googlegroups.com<mailto:regiops+unsubscribe@googlegroups.com>. To post to this group, send email to regiops(a)googlegroups.com<mailto:regiops@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/regiops/BN6PR12MB181046678BBEA9E2EF0830A9…<https://groups.google.com/d/msgid/regiops/BN6PR12MB181046678BBEA9E2EF0830A9…>. For more options, visit https://groups.google.com/d/optout.

1 0