- gtld-tech - lists.icann.org

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