- gtld-tech - lists.icann.org

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