April 2014 - gtld-tech - lists.icann.org

Handling of "loc" and "int" contacts
by Alexander Mayrhofer July 18, 2014

July 18, 2014

All, We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements) we're looking into the options to move forward with allowing "loc" postalInfo types as well. I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback: - For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, "int" optional - For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc"?) - For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?) - Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables? Feedback appreciated :) thanks, Alex

6 5

Call for Presentations for TechDay at ICANN London
by Dr Eberhard W Lisse April 26, 2014

April 26, 2014

As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in London Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz This time we would like to have a focus on "(Big) Data", if possible, preferably DNS related data, ie query analysis etc, but also methods. As we have no budget presenters are responsible for their own transport and room and board. As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O 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

spec5-reserved-names Legal Notice?
by Colosi, John April 22, 2014

April 22, 2014

Folks, Considering the spec5-reserved-names<https://github.com/centralnic/spec5-reserved-names> github repo that Gavin organized. I was wondering if the repo should have some kind of legal disclaimer saying essentially that folks should use it at their own risk. The community has done their best job of interpreting the ICANN guidelines, but it’s up to users to implement things in a way that meets their own contractual obligations. May be this isn’t necessary. Thoughts? -- John John Colosi Senior Manager of Product Development JColosi(a)Verisign.com m: 703-967-4062 t: 703-948-3211 12061 Bluemont Way, Reston VA 20190 VerisignInc.com<http://www.verisigninc.com/> [Verisign™] “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 1

Registrar IDs for new gTLDs
by Rubens Kuhl April 8, 2014

April 8, 2014

Hi there. After seeing Francisco Arias's presentation during ICANN Singapore, I had a doubt that one person also asked during the session: if the agreement only specifies 9999 as Registrar ID, can we divide the registrations depending on its billable nature between 9998 and 9999 without breaking the agreement ? Agreement text says: "02 iana-id For cases where the registry operator acts as registrar (i.e., without the use of an ICANN accredited registrar) 9999 should be used, otherwise the sponsoring Registrar IANA id should be used as specified in http://www.iana.org/assignments/registrar-ids " Any thoughts on that ? Any ICANN clarifications on this ? Tks, Rubens NIC.br

5 6

An on-going IETF discussion
by Edward Lewis April 7, 2014

April 7, 2014

Hi folks, (First time I’ve been on this list…but I think a few on the list already know me - I looked at some of the archives. I used to work with one gTLD, now I’m doing leg work for ICANN.) There’s a discussion in the IETF’s DNS Operations Working Group that people here might want to tune into and perhaps provide input. The message setting this up is here: http://www.ietf.org/mail-archive/web/dnsop/current/msg11543.html (And BTW, check this out too: http://www.ietf.org/mail-archive/web/dnsop/current/msg11542.html) The discussion is around an IETF *standards track* proposal to define a mechanism for how a registrant would signal to a registry that it has changed it’s NS set and/or glue records. The reason I’m bringing this up is: 1) The IETF believes that documenting this approach is better than not documenting, because they are concerned about delegations that do not fit the “ICANN model.” 2) The IETF wants and needs to hear from real operators. 3) In my opinion, this mechanism isn’t be workable for the gTLD environment. But, what do I know? So, I’m asking for those who have the time to take a look at the document and make comments on it - if not to the DNSOP list, to the DNSOP chairs or listed authors/editors. I don’t think the effort is dangerous, per se, but there are times that RFCs are pulled into RFPs for registry services. IMHO, I wouldn’t want this to become something asked of large registries. Perhaps I’m being paranoid, I say this to perhaps motivate people to read and comment. ;) Deadline is April 16 for the last call in the message (11543) above. Ed Lewis (aka edward.lewis(a)icann.org)

1 0