martes, 14 de marzo de 2017

What's the future for the .tel domain name?

What's the future for the .tel domain name?


Good news! is being relaunched with a slew of new features which frees it up from its previous shackles.

What is .tel

Your address book is probably a mausoleum - stuffed with the rotting corpses of long dead phone numbers. Perhaps you took my business card back in 2002, duly entered it on your Palm Pilot, and never spoke to me again. That address book entry has a phone number I've not used for a decade, an email address provided by a defunct start-up, and a postal address for a country I no longer live in.
Isn't there a better way?
That's what .tel was supposed to be.
  • I register a .tel domain - http://edent.tel
  • I fill it with my contact details.
  • You store my .tel in your address book.
  • When I change my phone number, I update my .tel and your phonebook receives the changes.
The magic of .tel is that everything is stored in the DNS. It shouldn't matter if the website goes down - or even if you've got low connectivity. All you need to do to get my details is:
dig @8.8.8.8 edent.tel naptr
Or, to get everything in the DNS records:
dig +nocmd edent.tel any +multiline +noall +answer
The tragedy of .tel is that there was almost no UI customisation available. Every site looked close to identical, corporate colour schemes couldn't be easily integrated, and the design was limited.
This is what it looked like back in 2009:
A plain looking website
Which, thankfully, had improved by 2013:
A screenshot of the original .tel platform
No further improvements were made.
So, how well did it work in practice?

Lack of critical mass

Back in 2012, there were 256k .tel domains. In 2016, it's a mere 105k domains. Those numbers need to be in the multi-millions in order to get the traction needed for success. In their original proposal, they were expecting 20 million registrations five years after launch.
As registrations fell, so did income. Senior staff left the .tel organisation, and the infrastructure was left to rot. There were no updates, and it looked like .tel might collapse - an unprecedented event in DNS history.
I worked in the mobile industry for a decade. I don't think I ever met anyone else with a .tel. I got mine when they first launched in 2009 - and have been lonely ever since.
As far as I can tell, no mobile phones were ever released which had .tel capable address books.

Relaunch!

Late last year, .tel owners were sent emails describing the upcoming relaunch and reinvigoration of the service.
✓ Lifting of usage restrictions.
✓ A new Telhosting platform.
✓ Android and iPhone apps.
✘ No porting of data!
✘ No sub-pages.
✘ No search.
✘ No advertising.
✘ Limited foreign language support.
It's a bit of a mixed bag. But, hopefully, there's enough to sustain numbers - if not increase them.
The most important is the lifting of hosting and design restrictions. Users will be able to point their .tel at any site they like. The idea of it just being an address book is disappearing.
For those people who do want to keep it as their virtual contact card - a new platform is being launched with an improved interface and fewer design restrictions. It will still be free of charge for domain owners.
As far as I can tell, this also means that sites can be secured with https - something which was unavailable on the old system.
Apps will be available for editing your site - but it would be a lot more useful to integrate with native address books.
It is downright odd that they're not automatically porting over peoples' data. There's going to be a one month grace period before launch in mid-March, but that isn't a huge amount of time.
The lack of sub-pages and search probably reflects how little those features were used. Removing Ad-Sense seems weird - but people can always add their own advertising.
They're also dropping support for "Arabic, Czech, Japanese, Korean, Portuguese and Russian" - I have no idea what those languages have in common! I assume they just mean that their hosting platform won't contain translations for those languages.

Is it enough?

I doubt it. Sorry to be so pessimistic - there are now literally hundreds of available top level domains. Including .mobi, .mobile, .phone, .call, .me - all of which could serve the same purpose.
If .tel had built on their early momentum - and perhaps done some deals with mobile networks or manufacturers - then perhaps .tel would be in a better position.
It is pretty neat that they can store data like this in the DNS, and it is more discoverable than .hcard or other microformats - but I fear that the idea of placing one's address details in DNS is doomed to failure.
Because they aren't porting existing data to the new system, I expect that a lot of existing .tel sites are going to be empty.

Bonus Retro Video

This is how .tel launched itself back in the day.
Bless!

miércoles, 14 de diciembre de 2016

10 domain name secrets to repair your online reputation

If you're trying to fix your personal reputation online, looking toward your domain name is a valuable first step. Columnist Chris Silver Smith explains some options beyond setting up YourName.com.

Online Reputation Domain Names If you’re trying to repair your personal reputation online, chances are you have already figured out that you might need one or more websites devoted to your name to help displace something negative in the search results. Beyond setting up YourName.com, what other options are there? Here are a few secrets that may help you get the search results all shiny again with less effort!
As part of good, proactive online reputation management and personal branding, I advise that everyone should own the basic “YourName.com” domain, particularly if one’s name is unique. If your name is common, like “John Smith,” it may not require as much proactive concern, but it would still be useful and recommended to set yourself up with a domain that features your proper name.
Some use this as a place to park their resumes online, and I’ve seen people simply redirect their proper name domains to their LinkedIn profiles or Facebook pages. If you ever run into a hater or a crazy person, you ought to own your name just as a defensive measure to keep it from being obtained to trash you.

It happened to me

I’m speaking about this from personal experience, unfortunately, since I once had someone register my professional name as a sort of threat to try to tarnish my name online. It was a very unusual situation. I had long operated my personal domain as “silvery.com,” which was intended to be clever and is closely similar to my nickname, Silver.
Simpler domains like “silver.com” and “silver.net” were already unavailable, of course, because they were snapped up by domainer speculators and then resold to jewelers and precious metal commodity companies. I had thought the domain was just fine for my personal branding; it didn’t occur to me that I might need other domain assets to protect myself from attacks.
Apparently, an individual who I had encountered at a company that I had previously consulted for felt threatened by my SEO knowledge and, perhaps due to professional jealousy, decided to start setting up “ChrisSilverSmith.com” to take me down a few notches. (Truly, I had never done anything to harm nor demean this individual, and I had gone out of my way to be polite to them despite some aggressive moves on their part.)
Out of the blue one day, I discovered ChrisSilverSmith.com to be ranking in Google a page or two back in the results. There was one page on the site, with an animated GIF or video on it of a humorous sequence from a popular online multiplayer game. But the Meta Description made clear it was aimed at me; it was similar or identical to the Meta Description on my personal site.
I didn’t know at first if it was intended to be a joke or if it was the first move in a hostile reputation attack campaign. The registration details were proxied, of course, to hide them. After a little digging, however, I was able to learn who was behind the registration. I considered what to do — such as legal options — but, I was initially determined not to allow the individual the satisfaction of attention, and I knew that I could use my experience and resources to keep the domain from affecting my professional work, if necessary.

How it turned out

Ultimately, I gently approached the people involved, diffused the situation and persuaded them to relinquish the domain, turning ownership over to me. No threats, no legal action. But many people in such a situation are not that lucky, and I realized how foolish I had been not to have already registered my full name as a domain name.
If you have any public persona whatsoever, you ought to proactively register your name as .COM, if it is available. I’ve known a lot of colleagues who’ve also faced brief, unwarranted attacks online, and I’ve dealt with a number of reputation clients who really should have already been operating a website paired up with a domain name optimized to be relevant for their personal name.
If you’re doing this proactively, perhaps you only need one domain name. But if you’re working to mitigate an attack on yourself, you may find setting up a small handful of domain names is more beneficial than setting up just your main one.

What to do if it happens to you

Either way, one question that often comes up is, “What should I do if MyName.com is unavailable?” Here are some of my secret tactics to help you maximize how effective your efforts will be.
The first, most basic principle is that a domain name that is an exact match for your name will be the most beneficial. Google and other search engines look at the keywords found in domain names when evaluating how relevant a website is to a user’s search query, and the closer the match, the easier it is for the site to rank higher in search results.
Google has worked to try to be sure that “official” websites for brands and individuals may rank highest for name searches, so the bar for achieving rankings is lower if you get an exact match domain. Negative materials are often just a page on another site, such as on RipoffReport.com, or perhaps Yelp, or horrific people-trashing sites like MyEx.com. Since those sites don’t have your name as a domain name, you can get an immediate advantage over them in ranking factors with your personalized domain.
I’ve run into many situations where people have used cute domain names for their personal websites, as I did for myself. Don’t make that mistake, because it won’t help in a reputation attack situation.
If your name is “John Smith,” then “JohnsHappyFunPlayhouse.com” is not going to be helpful. Yes, you can get a website with a different domain name to rank for your name searches, but it can require more effort in other areas.
Once you start searching on a domain registrar site, like GoDaddy.com, they will often suggest many top-level domain (TLD) alternatives to the “.COM” one. Some of these work better than others, depending on your situation. If you have a common name, the .COM option may be unavailable to you — so my tips for these options will be necessary for you.
By the way, people often ask if they should use their full name versus the more casual variations they use in personal life. It’s common to use your full name on your resume while asking people to use a shortened, familiar version in daily interactions. For instance, should I use “ChristopherSmith.com” or “ChrisSmith.com”?
The answer to this is: Use the variation that people will be most frequently searching upon and the name that has been used in any reputation attack online. If you go by both, you may need to be conducting reputation-strengthening campaigns for each name variation.
It is also possible to optimize a single website for both name variations by incorporating both names in the site’s text content and multiple SEO signals. But mostly, you just need to focus on the name that people are searching for.

10 online reputation domain name secrets

1. First, start with the grand-daddy standard domain of them all: .COM — The dot-com TLD is highly effective and preferable to register first as your primary website if it’s available. There are multiple reasons it’s effective: It’s one of the longest-established TLDs; it is the most-recognized top-level domain of all by both humans and machines; and it functions great from a marketing/branding standpoint, as well as from a technical standpoint.
If “YourName.com” is already taken, though, don’t despair. In some instances, slight name variations may work just as well.
For instance, dashes are allowed characters in domain names, and they can be used to delimit between first and last names, as in “Your-Name.com.” Many optimization experts avoid this out of fear that search engines may evaluate it to be a suspect domain and lower in quality and trustworthiness. But these fears may be largely unjustified, since dashed domains can function well. Admittedly, dashed domains are undesirable if you’d like to print your URL on your business cards and in other offline media.
Adding just a few letters near the end of the name can function well, too, in certain circumstances. Example: ChrisSmithCEO.com or JamesSmithBanker.com. Mostly, avoid tacking on additional words or letters, though, or you start eroding your exact-match domain advantage. Longer domains/URLs function correspondingly worse in search engines, so only adding very few letters should be considered if your options are limited.
2. .NET, .BIZ, .US, .ORG — If you search for your name with most registrars, they are likely to list these TLDs as options for you. In general, each one of these can function fairly well, closely similar to .COM.
I would say that in general, none of these confer any specialized advantages, but they can work quite well as simple, solid TLD extensions on a proper name domain. (One of my close friends has operated “John.org” since 1998, but I think he mainly maintains it just for his email address. It does indeed rank very well for a few queries, which is mildly surprising, since there’s no optimization put into it, and it’s not at all focused on his full name.)
3. Treat yourself to a .ME domain — While this is technically the TLD for the country of Montenegro, the government there decided to operate it as a Generic Top-Level Domain (gTLD), because they recognized that it held a wide commercial appeal worldwide, since “Me” is the English self-referencing pronoun. Domains with the .ME extension can function very well in search results, and the extension has a decent degree of recognizability. It’s short; it makes sense; it seems to convey that it’s operated by the person bearing the name used in the domain — it’s simply elegant!
A related alternative with differing advantages is to use the About.me service to set up a profile page for yourself at About.me/Your.Name; this service has inbuilt website design/publishing capabilities and likely has some degree of ranking capabilities, fresh out of the box. I probably wouldn’t recommend having both YourName.me and About.me/Your.Name simultaneously, though — use one or the other.
4. Geographic TLDs — Examples of Geographic TLDs: YourName.NYC, YourName.Miami, YourName.Paris. In a lot of reputation management cases, an individual’s name is closely associated with their local geographic areas in search results, rather than being prominent nationwide. A common case for this is when well-known proprietors of local businesses may be searched for with higher frequency in their cities than elsewhere, and Google will present different search result rankings according to geography for this reason.
For instance, in most places in the US, if you search for “Chris Silver Smith,” my site is likely to come up at the top of search results (since I speak nationwide at conferences and work professionally nationwide). However, if you search in the Miami area, Google is more likely to present web pages about an attorney, Chris Silversmith, who lives and works there.
If you are best-known in your local area, one great option for you would be to set up a personal website using a GeoTLD that is in sync with your geography. So Chris Silversmith could leverage his location associatively by setting up a personal web page on “ChrisSilversmith.miami,” and it would likely rank quite favorably in search results. My research indicates that these GeoTLDs perform quite advantageously in local search results, and SEO strategist Bill Hartzer has had similar findings.
5. Combine a subdomain with a domain — If you can’t obtain “FirstnameLastname.com,” which is likely if it’s at all common, then there’s a possibility you could obtain “Lastname.com.” And if you do that, you can set up a customized subdomain using your First Name: http://Firstname.lastname.com — wonderfully, this can accomplish very good optimization.
To obtain full benefit, be sure to 301 redirect the .www and non-.www versions of the site domain URLs over to the first/last name subdomain combination.
6. Use keyworded gTLDs — Honestly, this is a great tactic to use for many professionals online as their overall commercial optimization. Attorneys could use .LAWYER, .ATTORNEY or .LEGAL domain names. For doctors, .CARE, .HEALTHCARE, .SURGERY may be great options. Indeed, quite a few professions are covered, such as: .ACCOUNTANT, .ACTOR, .CONTRACTORS, .DENTIST, .BANK, .REALTOR and many others.
Considering that the reputations of many small businesses are as associated with the names of their founders/owners as they are with the company brand names, this is an overall good search marketing tactic. (It’s not as hot when performing offline marketing, such as in print or radio ads, because people still don’t recognize these newer top-level domains as much as the .COM/.NET standbys. But you could still use a more recognizable domain name variation in your offline marketing which just redirects to the keyworded gTLD.) I find that the shorter gTLDs function best for optimization, in part simply because shorter URLs function better in search.
7. Add a misspelling domain — If your ideal, exact-match domain name isn’t available, you may be able to use a misspelling to obtain virtually the same level of advantage. If “JohnSmith.com” isn’t available, “JohnSmiths.com” may work just as well. Google and other search engines have worked very hard to handle plurals/singulars and stemming variations of words, often treating them nearly identically.
In addition, using slight, common variations in the spelling of names may also work. Of course, the rest of the SEO of the site needs to focus still on the proper, exact-match spelling of the name in most cases. But a closely similar domain name will be an advantage when you cannot obtain exact matches. (In fact, even performing a complete optimization campaign more fully around a misspelling may provide additional assets to rank for the target name, since Google tries to incorporate a lot of variation in search results.)
8. Add a .TEL domain — Many marketers are seemingly unaware of this unique domain; it was set up as an internet directory service, with all types of contact information stored directly within the domain name system (DNS) information about each domain. So, the information you put on your .TEL domain will be republished on many of the sites that publish domain WHOIS information.
Naturally, you could include all sorts of things — your street address, city, state, ZIP and phone number — but, you could also include a biographic description of yourself, links to Facebook, Twitter and other social media, photos and more! .TEL automatically displays your domain’s information on the domain URL, marked up in HTML and Card Microformat. (Can you say, “citations for local SEO?”)
Telnic, the organization that administers the .TEL domain names, has also set up a directory of links to help ensure that all of the many .TELs become indexed in Google and Bing. I have found that by also adding some independent links pointing into a .TEL domain, one may further help it achieve good rankings.

lunes, 12 de diciembre de 2016

Nuevas caracteristicas de los dominios .tel

Dear valued .tel community member,

As 2016 draws to a close, we would like to take this opportunity to thank you for your continued support and being part of the .tel community. It is with great pleasure that we are also able to share with you some exciting news for 2017 which we believe will provide you with a new and enhanced product experience, greater flexibility and choice with respect to the application and use of your .tel domains and facilitate innovation in our namespace.


2016 – A Milestone year for Telnic and its community

2016 has been a milestone year for Telnic and one which we believe provides us with a firm platform to deliver on the feedback and requests of our community members and thus increase the value and usage potential of your .tel domain.

Lifting of usage restrictions

As a direct result of your feedback, Telnic has successfully negotiated the lifting of usage restrictions from your .tel domain. This means that you will now be able to use your .tel to design and host your own website and other digital services of your choosing. This freedom of choice has been a recurring request from community members and we are delighted to now offer you this option.

A new Telhosting platform

We are also marking this giant milestone in .tel’s history by providing our community with an optional, new and modernised Telhosting platform. The new platform has been designed based on extensive community feedback and usage patterns observed with the current system.

Staying true to our sponsored status, .tel is the universally recognised web address for publishing contact details online and is still primarily intended to serve the needs of individuals and businesses that wish to store their contact information using the DNS. On this basis, the new Telhosting platform offers you a compact, feature rich, single page solution to hosting and publishing your very own digital profile. Your new site can be totally managed using our new and free iPhone and Android smartphone apps or using our new desktop control panel and all for the same competitively low annual subscription fee.

We have set up an example digital profile page at http://telpage.tel for you to get a better feel for how you can leverage the functionality of the new platform to create a great looking .tel. With lots of new features such as more advanced custom design capability, PayPal integration, voucher and offers, PDF publishing and image library, we know you are going to enjoy and benefit from the new product experience to create a richer more customized and contemporary digital profile.



Some examples of great looking .tel domains created on the new platform using our desktop control panel or iOS and Android smartphone apps


Retiring the current Telhosting platform

As a result of launching our new Telhosting platform, we will be retiring the current Telhosting platform and there will be certain features such as sub domains, search and data privacy which will not be available in the new platform. Our attached FAQ provides a more detailed list of the differences between the current and new platforms.

We feel that our new platform offers you incredible value for money and is a great entry level hosting solution for establishing and managing your own digital identity and being found in search. If however, you feel that this new product is not for you then that is fine too and you will soon be able to utilize your .tel domain for other purposes of your choosing.

What is happening and when?

  • From the 13th February 2017, Telnic will issue you (by email) with account details to the new Telhosting platform. Once you receive your new details, you can access your new account and start adding content.
  • From 13th March 2017, any content that you have added to the new platform will be published to the internet from the new platform. From this date, content on the current platform will stop being published to the internet.
  • It is important to note that Telnic will not be performing any Data Migration from the current to new platform. Your new account will be empty and it will be your responsibility to populate your domain on the new platform before 13th March 2017.
  • From 13th March 2017, all usage restrictions will be lifted from .tel and you get to choose how you use your .tel domain.

Important information for directory builders and sub domain users

Telnic is very conscious and appreciative of the hard work and effort expended by many .tel owners who have developed directory sites using the sub domain functionality. Unfortunately, Telnic is unable to dual run the current and new platform and will not be offering sub domain functionality in the new platform. You are advised to back up your domain data from the current platform using the BACKUP function as soon as possible and by 12th March 2017 at the latest. This will produce an XML file containing all of your data which can then be used as a data source for populating your very own, independent database and service offering outside of Telhosting.

This data will not be accessible to after the 13th March 2017 therefore it is extremely important to make this backup copy if you wish to keep and use this data in future endeavours.

Should you wish to continue to host your domain on a version to the current Telhosting platform which incorporates sub domains, please contact us at cservice@telnic.org and we will discuss options available to you.

Customer support for the new platform

Up until now, your registrar or reseller has provided you with access to and support for the Telhosting platform. Starting on the 13th of March 2017, Telnic will assume this responsibility. For all new platform .tel hosting product support requests from 13th March 2017 onwards, please contact cservice@telnic.org. Questions relating to domain lifecycle activities such as registration, renewal, WHOIS updates etc should continue to be directed to your registrar or reseller.

Next steps

An FAQ is provided below to help you further understand the nature of the forthcoming changes and how they may impact you. These changes present new and exciting opportunities for the .tel community. Over the next few months, we will be sending out further communications to keep you fully updated with developments and timescales to ensure a smooth transition.

I hope that you are as excited as we are by this news and we look forward to working with you to grow the .tel community.  If you have any questions, please contact us at cservice@telnic.org

Kindest Regards,

Khashayar Mahdavi
CEO
Telnic Ltd


FAQ


1. When will the restrictions be lifted from .tel and what will be my options then be for using my domain?

All restrictions will be lifted from .tel on 13th March 2017. From this date, and subject to your registrar or reseller support, you will be able to use your .tel domain as a normal website, continue to take advantage of our free, new Telhosting platform or opt for a paid for Telhosting service which incorporates sub domains with a 3rd party hosting provider.

2. When will I be able access my new Telhosting account?

From 13th February 2017, Telnic will issue (by email) new Telhosting account details to all .tel owners. From this date, .tel owners will be able to log in and manage content on the new platform. Please note that this content will not display on the internet until the current Telhosting platform is retired on 13th March 2017.

3. What happens if I do not receive my new account details by end of February 2017?

If you have not received account details for your new Telhosting account by the end of February 2017, you should contact Telnic by sending an email to cservice@telnic.org confirming the domain name(s) in question. We will be using the email address that you have stored in your old Telhosting account profile for your new TelHosting account. Additionally we will use the email address that is associated with the domain registrant in our WHOIS to contact you. To ensure that you receive our communications, you are advised to ensure that these email addresses are current and accurate.

4. When will the current Telhosting platform be retired?

The current Telhosting platform will be retired and taken offline on 13th March 2017. You can continue to use the current Telhosting platform up to 12th March 2017 but not after this date.

5. What happens to my data on the current Telhosting platform after 13th March 2017?

.tel domain owner data that resides on the current Telhosting system will not be accessible after 13th March 2017. Any .tel domain owner that wishes to extract a copy of their data from the current system should run the BACKUP function from their current Telhosting account before 13th March 2017. This will produce an XML file containing all of their data which can be used either as a reference for populating their new account or as a data source for populating an independent and separate 3rd party hosting solution.

6. What happens if I do not make a copy of my data before the 13th March 2017?

If you do not make a copy of your data before 13th March 2017, the data will be deleted and not recoverable as the current Telhosting platform is being retired.

7. Why is Telnic not migrating my data from the current Telhosting platform to the new?

The current Telhosting platform is being retired and the new platform is not designed as a like for like replacement in terms of functionality or data structure. As such, there is no direct data migration path from old to new so you will need to log in and republish your contact records in order to take advantage of new functionality that does not exist in the curent platform. The vast majority of .tel owners only publish a single page of contacts and content and re-publishing will be a very quick exercise.

8. What if I wish to continue to host my .tel domain on a platform that supports sub domains?

The current Telhosting platform will be shutdown on 13th March 2017. If you would like to continue to host your .tel domain on a similar Telhosting platform that supports sub domains please contact cservice@telnic.org and we will help you to review hosting options

9. What happens to any new .tel domains that I register before 13th March 2017?

Up to 13th March 2017, you will continue to manage your .tel for live internet publishing purposes on the current platform.

10. What happens to any new .tel domains that I buy after 13th March 2017?

After 13th March 2017, you will receive information from your registrar and Telnic informing you of the process to claim your free hosting account for your new .tel domain. Telnic’s web site (www.telnic.org) will have a page dedicated to Telhosting management. On this page, .tel owners will be able to set up a new telhosting account, add .tel domains to an existing account as well as manage their domain(s) and request support.

Alternatively, you may opt to use your .tel for a purpose of your own choosing.

11. What happens if I do not access my new Telhosting account and add some contacts or content?

The content from your current Telhosting account will disappear on 13th March 2017. If you have not populated your new Telhosting account with any data by this date, your .tel domain will show a standard template page. Any content that you add after 13th March will automatically be published.

12. What happens if I take no action before 13th March 2017?

If you do not take any action before 13th March 2017, an account will be automatically created for you and your domains on the new Telhosting platform and we will send you the access details by email. Your new account and domains will remain empty and inactive until you login and add content. Your account and data on the current Telhosting system will not be accessible after 12th March 2017 so it is important that you backup any data you wish to keep before this date.

13. Is there a smartphone app to help manage my .tel domain content on the new Telhosting platform?

Yes. Telnic will have a new iOS and Android app that will enable .tel owners using Telhosting to fully manage their domain content using their smartphone. Free downloads will be available from our web site or from the Apple and Google Play stores. These apps will be available for download in March 2017.

14. What are the functional differences between the current and new Telhosting platforms?

The new Telhosting platform will be a single page product.  You can see an example of the new product in use at:  http://telpage.tel. It provides a more modern interface that allows the user to:

  • Publish contact and content records
  • Add PDF documents
  • Add Promotional product/service offers
  • Add Images and Video
  • Sell Products and services via a PayPal interface
  • Add custom design
  • Add an image advert

The new platform does not support a number of features from the current platform detailed in the list below. The decision to exclude these features was based on customer feedback and usage statistics.

  • Multiple pages or sub-domains
  • Telfriends and private data support
  • .tel search functionality
  • Multiple profile support
  • Telhosting product language support for Arabic, Czech, Japanese, Korean, Portuguese and Russian.
  • SOAP API access for registrars and domain owners
  • Google Ad sense integration

15. How will Telnic support the new Telhosting platform?

From 13th March 2017, all support requests from domain owners that use the new Telhosting platform should be sent to cservice@telnic.org . Telnic will handle these requests directly.

16. If I am not using the Telhosting platform, who do I contact for .tel domain support?

Starting 13th March 2017, if you have questions about your domain name and are not using the Telhosting platform, you should contact your registrar or reseller for support or the 3rd party hosting provider if you have opted to use this service.

17. Will domain owners be charged for the new Telhosting platform?

No. Telnic will continue to provide a free and optional Telhosting service to all .tel community members.

18. Will my domain registration and ownership status be affected by the Telhosting changes?

No. You will continue to be the owner of your .tel domain and there is no change to the contractual relationship you have with your registrar or reseller with respect to domain renewal and other domain specific activities such as transfers and WHOIS updates. Your registrar will still be your point of contact with respect to these key domain lifecycle activities.

martes, 8 de noviembre de 2016

El futuro de los 10 próximos años de los dominios .tel (2016-2026)

Adopted Board Resolutions | Regular Meeting of the ICANN Board


  1. Consent Agenda:
    1. Approval of Board Meeting Minutes
    2. Stability Advisory Committee (SSAC) Member Appointments
    3. Stability Advisory Committee (SSAC) Member Reappointments
    4. Appointment of D-, E-, G-, and H-Root Server Operator Representatives to the Root Server System Advisory Committee (RSSAC)
    5. Investment of Auction Proceeds
    6. ICANN Delegation of Authority Guidelines
    7. Renewal of .TEL Registry Agreement
    8. Thank You to Community Members
    9. Thank You to Local Host of ICANN 57 Meeting
    10. Thank You to Sponsors of ICANN 57 Meeting
    11. Thank You to Interpreters, Staff, Event and Hotel Teams of ICANN 57 Meeting
  2. Main Agenda:
    1. Two-Character Domain Names in the New gTLD Namespace
    2. Consideration of the Corn Lake, LLC v. ICANN Independent Review Process Final Declaration
    3. Thank You to the Global Multistakeholder Community
    4. Thank You to Bruno Lanvin for his service to the ICANN Board
    5. Thank You to Erika Mann for her service to the ICANN Board
    6. Thank You to Kuo-Wei Wu for his service to the ICANN Board
    7. Thank You to Suzanne Woolf for her service to the ICANN Board
    8. Thank You to Bruce Tonkin for his service to the ICANN Board
  1. Consent Agenda:

    1. Approval of Board Meeting Minutes

      Resolved (2016.11.08.01), the Board approves the minutes of the 9 August, 15 August, 17 September and 30 September 2016 meetings of the ICANN Board.
    2. Stability Advisory Committee (SSAC) Member Appointments

      Whereas, the Security and Stability Advisory Committee (SSAC) reviews its membership and makes adjustments from time-to-time.
      Whereas, the SSAC Membership Committee, on behalf of the SSAC, requests that the Board should appoint Jacques Latour and Tara Whalen to the SSAC for three-year terms beginning immediately upon approval of the Board and ending on 31 December 2019.
      Resolved (2016.11.08.02), that the Board appoints Jacques Latour and Tara Whalen to the SSAC for three-year terms beginning immediately upon approval of the Board and ending on 31 December 2019.

      Rationale for Resolution 2016.11.08.02

      The SSAC is a diverse group of individuals whose expertise in specific subject matters enables the SSAC to fulfill its charter and execute its mission.  Since its inception, the SSAC has invited individuals with deep knowledge and experience in technical and security areas that are critical to the security and stability of the Internet’s naming and address allocation systems.
      The SSAC’s continued operation as a competent body is dependent on the accrual of talented subject matter experts who have consented to volunteer their time and energies to the execution of the SSAC mission.  Jacques Latour is currently the CTO at CIRA, the Canadian Internet Registry Authority for .CA, a position he has held for the past 6 years. He also is an active member of the ccNSO community and the IETF DNS community. Jacques has extensive country code registry experience and all of the related technologies. He has been an active member of the SSAC’s DNSSEC Workshop Program Committee for several years.
      Tara Whalen has a PhD in Computer Science followed by a Masters in Law with a concentration in Law and Technology. She has over 20 years of experience in security and privacy, including working in the Office of the Privacy Commissioner of Canada, as a Privacy and Security Standards Engineer at Apple, and is currently a Staff Privacy Analyst at Google. She has been active in the IETF (intrusion detection working group) and is currently active in the W3C (Privacy Interest Group). She is generally engaged in an operational role around the nexus of security and privacy.
      The SSAC believes Jacques Latour and Tara Whalen would be significant contributing members of the SSAC.
    3. Stability Advisory Committee (SSAC) Member Reappointments

      Whereas, Article 12, Section 12.2(b) of the Bylaws governs the Security and Stability Advisory Committee (SSAC).
      Whereas, the Board, at Resolution 2010.08.05.07 approved Bylaws revisions that created three-year terms for SSAC members, required staggering of terms, and obligated the SSAC Chair to recommend the reappointment of all current SSAC members to full or partial terms to implement the Bylaws revisions.
      Whereas, the Board, at Resolution 2010.08.05.08 appointed SSAC members to terms of one, two, and three years beginning on 01 January 2011 and ending on 31 December 2011, 31 December 2012, and 31 December 2013.
      Whereas, in January 2016 the SSAC Membership Committee initiated an annual review of SSAC members whose terms are ending 31 December 2016 and submitted to the SSAC its recommendations for reappointments in September 2016.
      Whereas, on 21 September 2016, the SSAC members approved the reappointments.
      Whereas, the SSAC recommends that the Board reappoint the following SSAC members to three-year terms: Jeff Bedser, Ben Butler, Merike Kaeo, Warren Kumari, Xiaodong Lee, Carlos Martinez, and Danny McPherson.
      Resolved (2016.11.08.03), the Board accepts the recommendation of the SSAC and reappoints the following SSAC members to three-year terms beginning 01 January 2017 and ending 31 December 2019: Jeff Bedser, Ben Butler, Merike Kaeo, Warren Kumari, Xiaodong Lee, Carlos Martinez, and Danny McPherson.

      Rationale for Resolution 2016.11.08.03

      The SSAC is a diverse group of individuals whose expertise in specific subject matters enables the SSAC to fulfill its charter and execute its mission.  Since its inception, the SSAC has invited individuals with deep knowledge and experience in technical and security areas that are critical to the security and stability of the Internet’s naming and address allocation systems.  The above-mentioned individuals provide the SSAC with the expertise and experience required for the Committee to fulfill its charter and execute its mission.
    4. Appointment of D-, E-, G-, and H-Root Server Operator Representatives to the Root Server System Advisory Committee (RSSAC)

      Whereas, the ICANN Bylaws call for the establishment of a Root Server System Advisory Committee (RSSAC) with the role to advise the ICANN community and ICANN Board of Directors on matters relating to the operation, administration, security, and integrity of the Internet’s Root Server System.
      Whereas, the ICANN Bylaws call for the ICANN Board of Directors to appoint one RSSAC member from each Root Server operator organization, based on recommendations from the RSSAC Co-Chairs.
      Whereas, the RSSAC Co-Chairs have recommended for ICANN Board of Directors consideration the appointment of representatives from the D-, E-, G, and H-root server operators to the RSSAC.
      Resolved (2016.11.08.04), the Board appoints to the RSSAC the following representatives from the D-, E-, G-, and H-root server operators: Tripti Sinha, Kevin Jones, Kevin Wright, and Howard Kash, respectively, through 31 December 2019.

      Rationale for Resolution 2016.11.08.04

      In May 2013, the root server operators (RSO) agreed to an initial membership of RSO representatives for RSSAC, and each RSO nominated an individual. The ICANN Board of Directors approved the initial membership of RSSAC in July 2013 with staggered terms.
      The representatives from the D-, E-, G-, and H-root server operators were appointed to an initial three-year term, which expires on 31 December 2016. These appointments are for full, three-year terms.
      The appointment of these RSSAC members is not anticipated to have any fiscal impact on ICANN, though there are budgeted resources necessary for ongoing support of the RSSAC.
      This resolution is an organizational administrative function for which no public comment is required. The appointment of RSSAC members contributes to ICANN’s commitment to strengthening the security, stability, and resiliency of the DNS.
    5. Investment of Auction Proceeds

      Whereas, to date ICANN has collected US$233 million of auction proceeds.
      Whereas, the Board Finance Committee has determined that auction proceeds need to be invested in a manner that preserves capital and keeps these funds readily available.
      Whereas, the Board Finance Committee recommends that auction proceeds be distributed across three different investment managers, and invested in safe and liquid financial instruments.
      Resolved (2016.11.08.05), the Board authorizes the President and CEO, or his designee(s), to take all actions necessary to distribute the auction proceeds across three different investment managers, which will be tasked with investing those proceeds in safe and liquid financial instruments.

      Rationale for Resolution 2016.11.08.05

      To date ICANN has collected auction proceeds totaling US$233 million. ICANN continuously mitigates the risk of custody by distributing investments across more than one investment management firm. Considering the amount of auction proceeds collected to date, the number of firms used to manage these funds need to be increased from the one firm currently used, to three firms. Through an RFP conducted in 2013 for the New gTLD Program, ICANN has already qualified three investment management firms. The auction funds will be distributed across these three firms, in separate and distinct accounts holding exclusively auction proceeds. In addition, considering the intended usage of these funds in the near future, as per the ongoing community process, the BFC has recommended that the managers hold these funds in safe and liquid financial instruments.
      As a result, the organization recommends that the auction proceeds be invested at three different investment managers to reduce the risk of custody, and be invested in safe and liquid financial instruments.
      This action is not expected to have any fiscal impact, or any impact on the security, stability and resiliency of the domain name system.
      This is an Organizational Administrative Function that does not require public comment.
    6. ICANN Delegation of Authority Guidelines

      Whereas, ICANN Bylaws Article 2 establishes that with certain exceptions, the powers of ICANN shall be exercised by, and its property controlled and its business and affairs conducted by or under the direction of, the Board.
      Whereas, ICANN Bylaws Article 15 establishes officers of ICANN, and designates the President to be the Chief Executive Officer (CEO) of ICANN in charge of all of its activities and business. All other officers and staff shall report to the President or his or her delegate, unless stated otherwise in the Bylaws.
      Whereas, the Board desires to set out a clear line of delegation of authority between the role of the Board and the roles of CEO and management.
      Resolved (2016.11.08.06), the Board hereby adopts the “ICANN Delegation of Authority Guidelines” to provide clear guidance and clarification of roles between the ICANN Board and the ICANN CEO/Management (“Guidelines”).  The Guidelines shall be reviewed regularly and amended from time to time by resolution of the Board.

      Rationale for Resolution 2016.11.08.06

      The Board is taking action at this time to adopt a set of guidelines to provide greater clarity of roles between the Board and CEO/Management. These guidelines, titled “ICANN Delegation of Authority Guidelines,” identify the respective key roles of the Board, key roles of CEO/Management, and the key interdependencies in those relationships. As outlined in the Guidelines, a primary source of the Board’s powers come directly from the ICANN Bylaws, as well as internal policies. Among others, these key powers include: (1) acting collectively by voting at meetings to authorize and direct management to take action on behalf of the ICANN organization, (2) interacting with the ICANN community to ensure that ICANN is serving the global public interest within ICANN’s mission, and (3) considering policy recommendations arising out of Supporting Organizations, including participating in consultation processes if necessary.
      The ICANN CEO is authorized to act within the authority delegated by the Board. The CEO may designate key management to assist in carrying out these responsibilities. The CEO’s responsibilities, include, but are not limited to: (1) interacting with the ICANN community to ensure that ICANN is serving the global public interest within ICANN’s mission, (2) maintaining open lines of communication with the Board, (3) interacting with governments within the scope of ICANN’s mission and Board’s directives, and (4) leading and overseeing ICANN’s day-to-day operations.
      By adopting these Guidelines, the Board intends to ensure that the Board and CEO/Management continue to operate within the scope of its mission. The Board’s approval of the Guidelines will have positive impact on the community as provides additional transparency and clarity about the roles and responsibilities of key members in the ICANN organization. Additionally, it provides additional accountability to the community by clearly defining the roles and responsibilities.
      There is no anticipated fiscal impact of the Board taking this action, and there are no expected security, stability, or resiliency issues related to the DNS associated with the Board’s approval of the Guidelines.
      This decision is an Organizational Administrative Function that does not require public comment.
    7. Renewal of .TEL Registry Agreement

      Whereas, ICANN commenced a public comment period from 04 August 2016 to 13 September 2016 on a proposed Renewal Registry Agreement for the .TEL TLD.
      Whereas, the proposed .TEL Renewal Registry Agreement includes modified provisions to bring the .TEL Registry Agreement into line with the form of the New gTLD Registry Agreement.
      Whereas, the public comment forum on the proposed Renewal Registry Agreement closed on 13 September 2016, with ICANN receiving twenty-seven (27) comments, both by individuals and organizations/groups. A summary and analysis of the comments were provided to the Board. ICANN modified the proposed Renewal Registry Agreement to correct typographical errors and to incorporate additional clarifying language in response to the public comments related to the RPM language proposed in Section 1 of Specification 7 regarding applicability and implementation of applicable rights protection mechanisms.
      Whereas, ICANN conducted a review of Telnic’s recent performance under the current .TEL Registry Agreement and found that Telnic substantially met its contractual requirements.
      Resolved (2016.11.08.07), the .TEL Renewal Registry Agreement, as revised, is approved and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to finalize and execute the Agreement.

      Rationale for Resolution 2016.11.08.07

      Why the Board is addressing the issue now?
      ICANN and Telnic Limited (the “Registry Operator”) entered into a Registry Agreement on 30 May 2006 for operation of the .TEL top-level domain. The current .TEL Registry Agreement expires on 01 March 2017. The proposed Renewal Registry Agreement was posted for public comment between 04 August 2016 and 13 September 2016. At this time, the Board is approving the Renewal Registry Agreement for the continued operation of the .TEL TLD by the Registry Operator.
      What is the proposal being considered?
      The revised Renewal Registry Agreement approved by the Board includes modified provisions to bring the Agreement into line with the form of the New gTLD Registry Agreement. The modifications include: updating technical specifications; adding Public Interest Commitments including the obligation to only use registrars under the 2013 Registrar Accreditation Agreement; and requiring the implementation of additional Rights Protection Mechanisms, namely the Uniform Rapid Suspension and the Post-Delegation Dispute Resolution Procedure.
      Specifically, all approved registry services in the current .TEL Registry Agreement carry over to the revised Renewal Registry Agreement. Such services include Bulk Transfer After Partial Portfolio Acquisition, Registry Controlled DNS Records Service, Domain data change notifications, Whois private contact information opt-out for Individuals, Special Access Service, Additional RDDS Data Fields and Internationalized Domain Names.
      With regard to the Schedule of Reserved Names, the revised Renewal Registry Agreement includes existing provisions permitting the Registry Operator to allocate previously reserved one and two-character names through ICANN-accredited registrars via a Phased Allocation Program. However, all single-character numerical labels continue to be reserved at the second level.
      As part of the adaptation needed to carry over the Sponsored TLD Charter of .TEL to the revised Renewal Registry Agreement, Specification 12 incorporates the language of the original Sponsorship Charter - Appendix S in the current .TEL TLD Agreement, with modifications to remove the requirement that the Registry control the name servers of delegated domain names, and the restriction that registrants cannot define the contents of the zone for their domain names. As .TEL was originally approved under this premise, the change will transform the .TEL TLD into a gTLD with a limited set of community parameters. These parameters will become optional rather than required.
      Which stakeholders or others were consulted?
      ICANN conducted a public comment period on the proposed .TEL Renewal Registry Agreement from 04 August 2016 through 13 September 2016, following which time the comments were summarized and analyzed. Additionally, ICANN engaged in bilateral negotiations with the Registry Operator to agree to the package of terms to be included in the proposed Renewal Registry Agreement that was posted for public comment.
      What concerns or issues were raised by the community?
      The proposed Renewal Registry Agreement was posted for public comment. Commenters expressed their views in three key areas during the public comment period:
      • Extension of .TEL Registry Agreement: Some of the commenters expressed support for the extension of .TEL Registry Agreement, while others suggested that improvements should be implemented for .TEL domain names if the .TEL Registry Agreement is to be extended.
      • Proposed Renewal Registry Agreement for .TEL: Three key issue areas were raised on the specific text of the renewal:
      • General Views – Some commenters positively noted there are technical and operational advantages to the New gTLD Registry Agreement form that serve as a benefit to registrants and the Internet community over earlier versions of the legacy Agreement. Additionally, there was support for ICANN’s efforts at bilateral negotiations with legacy TLD registries in order to transition to the New gTLD Registry Agreement and the procedural benefit of consistency that will come with ICANN’s bilaterally negotiating for transition to provisions of the New gTLD Registry Agreement not only with .TEL but with other legacy TLDs like .JOBS, .CAT, .PRO, and .TRAVEL.
      • Rights Protection Mechanisms – One commenter sought clarity over the language proposed in Section 1 of Specification 7 regarding applicability and implementation of rights protection mechanisms.
        • Registration Data Directory Service (Whois) – Some commenters raised concerns with continuing the unique Registration Data Directory Service that ICANN’s Board approved in 2007 for the .TEL TLD.
      • The continued operation of .TEL by Telnic Limited: Concerns were expressed over Telnic Limited continuing to be the Registry Operator of .TEL, claiming, among other things that Telnic has violated ICANN’s requirements several times and Telnic no longer has stable financials to continue the operation of .TEL.
      What significant materials did the Board review?
      As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents:
      What factors has the Board found to be significant?
      The Board carefully considered the public comments received for the Renewal Registry Agreement, along with the summary and analysis of those comments. The Board also considered the terms agreed to by the Registry Operator as part of the bilateral negotiations with ICANN. The Board acknowledges the concerns expressed by some community members regarding suggested improvements that should be implemented for .TEL domain names if the .TEL Registry Agreement is to be extended. However, the terms of the .TEL Registry Agreement set forth the contractual obligations that must be fulfilled by Telnic Limited in its operation of the .TEL registry but do not prescribe or proscribe the Registry Operators’ business model. Additionally, the Staff Report of Public Comment Proceeding encouraged those commenters that desire to see changes in the business model of the .TEL registry to contact Telnic Limited to discuss these matters.
      The Board acknowledges the request for clarity over the RPM language proposed in Section 1 of Specification 7 regarding applicability and implementation of applicable rights protection mechanisms. While the revisions to Specification 7 were consistent with prior legacies, a modification was made to the language of the Renewal Registry Agreement for .TEL to address the comment. The revision is now reflected in Section 1 of Specification 7 of the revised Renewal Registry Agreement to read “Registry Operator will include all RPMs required by this Specification and any additional RPMs developed and implemented by Registry Operator in the registry-registrar agreement entered into by ICANN-accredited registrars authorized to register names in the TLD.”
      The Board acknowledges the concerns raised with continuing the unique Registration Data Directory Service that the Board approved in 2007 for the .TEL TLD. The Board notes the 18 December 2007 Board Resolution that approved changes to .TEL’s Registration Data Directory Service (Whois) requirements was based on unique business and legal circumstances stating, “…the Board concludes that the requested modifications are justified by the unique business and legal circumstances of the .TEL top-level domain…” After conferring with Telnic Limited, ICANN has confirmed that, to the knowledge of the Registry Operator, the legal circumstances related to Registration Data Directory Service (Whois) have not changed. Therefore, the Registration Data Directory Service (Whois) requirements which were ultimately replicated from the prior agreement between ICANN and Telnic Limited will be retained in the Renewal Registry Agreement.
      Additionally, the Board has considered comments regarding the continued operation of .TEL by Telnic Limited, including concerns that Telnic has violated ICANN’s requirements several times and Telnic no longer has stable financials to continue the operation of .TEL. As part of the renewal process ICANN conducts a review of contractual compliance under the .TEL Registry Agreement. Telnic Limited was found to be in substantial compliance with their contractual requirements. Also, during the past 10 years of operation, ICANN has no knowledge of Telnic Limited experiencing financial or other operational impediments that have caused a failure of registry operations or security and stability concerns. If Telnic Limited were to experience financial problems that resulted in the Registry Operator failing to comply with its obligations under the Registry Agreement, ICANN can take action to protect registrants and ensure continuity of registry operations.
      Finally, the Board notes that existing Registry Agreement calls for presumptive renewal of the Agreement at its expiration so long as certain requirements are met. These provisions are intended to promote stability and security of the registry by encouraging long-term investment in TLD operations, which benefits the community in the form of reliable operation of registry infrastructure. The Renewal Registry Agreement is subject to the negotiation of renewal terms reasonably acceptable to ICANN and the Registry Operator. The renewal terms approved by the Board are the result of the bilateral negotiations called for in the current Registry Agreement.
      Are there positive or negative community impacts?
      The Board’s approval of the Renewal Registry Agreement also offers positive technical and operational benefits. Pursuant to the Renewal Registry Agreement, in the event that any of the emergency thresholds for registry functions is reached, Registry Operator agrees that ICANN may designate an emergency interim Registry Operator of the registry for the TLD, which would mitigate the risks to the stability and security of the Domain Name System. Also, technical onboarding of the Registry Operator to comply with the provisions in the New gTLD Agreement will allow the registry to use uniform and automated processes, which will facilitate operation of the TLD.
      There will also be positive impacts on registrars and registrants. The transition to the New gTLD Registry Agreement will provide consistency across all registries leading to a more predictable environment for end-users and also the fact that the proposed Renewal Registry Agreement requires that the Registry Operator uses ICANN accredited registrars that are party to the 2013 Registrar Accreditation Agreement (RAA) only will provide more benefits to registrars and registrants.
      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?
      There is no significant fiscal impact expected if ICANN approves the proposed .TEL Renewal Registry Agreement. It should be noted however that as a result of approval of the Renewal Registry Agreement, projected annual registry fees to ICANN will result in a minimal negative fiscal impact. This change has been considered in ICANN’s budget.
      Are there any security, stability or resiliency issues relating to the DNS?
      There are no expected security, stability, or resiliency issues related to the DNS if ICANN approves the proposed .TEL Renewal Registry Agreement. The proposed Renewal Registry Agreement in fact includes terms intended to allow for swifter action in the event of certain threats to the security or stability of the DNS. As part of ICANN’s organizational administrative function, ICANN posted the draft Renewal Registry Agreement for public comment on 04 August 2016.
    8. Thank You to Community Members

      Whereas, ICANN wishes to acknowledge the considerable effort, skills, and time that members of the stakeholder community contribute to ICANN.
      Whereas, in recognition of these contributions, ICANN wishes to acknowledge and thank members of the community when their terms of service end on the Supporting Organizations, Advisory Committees and Nominating Committee. 
      Whereas, the following members of the Address Supporting Organization are concluding their terms of service:
      • Dmitry Kohmanyuk, Address Supporting Organization Address Council Member
      • John Sweeting, Address Supporting Organization Address Council Member
      Resolved (2016.11.08.08), Dmitry Kohmanyuk and John Sweeting have earned the deep appreciation of the ICANN Board of Directors for their terms of service, and the ICANN Board of Directors wishes them well in their future endeavors within the ICANN community and beyond.
      Whereas, the following members of the County Code Names Supporting Organization are concluding their terms of service:
      • Becky Burr, County Code Names Supporting Organization Council Member
      • Celia Lerman Friedman, County Code Names Supporting Organization Council Member
      • Vika Mpisane, County Code Names Supporting Organization Council Member
      • Ron Sherwood, County Code Names Supporting Organization Liaison to the At-Large Advisory Committee
      Resolved (2016.11.08.09), Becky Burr, Celia Lerman Friedman, Vika Mpisane, and Ron Sherwood have earned the deep appreciation of the ICANN Board of Directors for their terms of service, and the ICANN Board of Directors wishes them well in their future endeavors within the ICANN community and beyond.
      Whereas, the following members of the Generic Names Supporting Organization are concluding their terms of service:
      • David Cake, Generic Names Supporting Organization Councilor
      • Mason Cole, Generic Names Supporting Organization Liaison to the Governmental Advisory Committee
      • Jennifer Gore, Generic Names Supporting Organization Councilor
      • Volker Greimann, Generic Names Supporting Organization Councilor
      • Carlos Raúl Gutiérrez, Councilor
      • Michele Neylon, Registrar Stakeholder Group Chair
      • Darcy Southwell, Registrar Stakeholder Group Vice Chair
      • Rudi Vansnick, Not-for-Profit Operational Concerns Constituency Chair
      Resolved (2016.11.08.10), David Cake, Mason Cole, Jennifer Gore, Volker Greimann, Carlos Raúl Gutiérrez, Michele Neylon, Darcy Southwell, and Rudi Vansnick have earned the deep appreciation of the ICANN Board of Directors for their terms of service, and the ICANN Board of Directors wishes them well in their future endeavors within the ICANN community and beyond.
      Whereas, the following members of the At-Large community are concluding their terms of service:
      • Satish Babu, Asian, Australasian and Pacific Islands Regional At-Large Organization Vice Chair
      • Humberto Carrasco, Latin American and Caribbean Islands Regional At-Large Organization Secretariat
      • Olivier Crépin-Leblond, At-Large Advisory Committee Liaison to the Generic Names Supporting Organization
      • Timothy Denton, At-Large Advisory Committee Member
      • Sandra Hoferichter, At-Large Advisory Committee Member
      • Barrack Otieno, African Regional At-Large Organization Secretariat
      • Vanda Scartezini, At-Large Advisory Committee Member
      • Jimmy Schulz, At-Large Advisory Committee Member
      • Alberto Soto, Latin American and Caribbean Islands Regional At-Large Organization Chair
      • Siranush Vardanyan, Asian, Australasian and Pacific Islands Regional At-Large Organization Chair
      Resolved (2016.11.08.11), Satish Babu, Humberto Carrasco, Olivier Crépin-Leblond, Timothy Denton, Sandra Hoferichter, Barrack Otieno, Vanda Scartezini, Jimmy Schulz, Alberto Soto, and Siranush Vardanyan have earned the deep appreciation of the ICANN Board of Directors for their terms of service, and the ICANN Board of Directors wishes them well in their future endeavors within the ICANN community and beyond.
      Whereas, the following members of the Root Server System Advisory Committee are concluding their terms of service:
      • Jim Cassell, Member
      • Ashley Heineman, National Telecommunications and Information Administration Liaison to the Root Server System Advisory Committee
      • Lars-Johan Liman, Co-Chair
      • Jim Martin, Member
      Resolved (2016.11.08.12), Jim Cassell, Ashley Heineman, Lars-Johan Liman, and Jim Martin have earned the deep appreciation of the ICANN Board of Directors for their terms of service, and the ICANN Board of Directors wishes them well in their future endeavors within the ICANN community and beyond.
      Whereas, the following member of the Security and Stability Advisory Committee is concluding his term of service:
      • Shinta Sato, Member
      Resolved (2016.11.08.13), Shinta Sato has earned the deep appreciation of the ICANN Board of Directors for his terms of service, and the ICANN Board of Directors wishes him well in their future endeavors within the ICANN community and beyond.
      Whereas, the following members of the Nominating Committee are concluding their terms of service:
      • Stephen Coates, Member
      • Sylvia Herlein Leite, Member
      • Hans Petter Holen, Chair-Elect
      • Zahid Jamil, Member
      • Wolfgang Kleinwächter, Associate Chair
      • Yrjö Länsipuro, Member
      • Stéphane Van Gelder, Chair
      Resolved (2016.11.08.14), Stephen Coates, Sylvia Herlein Leite, Hans Petter Holen, Zahid Jamil, Wolfgang Kleinwächter, Yrjö Länsipuro, and Stéphane Van Gelder have earned the deep appreciation of the ICANN Board of Directors for their terms of service, and the ICANN Board of Directors wishes them well in their future endeavors within the ICANN community and beyond.
    9. Thank You to Local Host of ICANN 57 Meeting

      The Board wishes to extend its thanks to the local host organizer, Minister Ravi Shankar Prasad and the Government of India including Ministry of Electronics and Information Technology, Ministry of External Affairs, National Security Council Secretariat, Ministry of Home Affairs, Government of Telangana and National Internet Exchange of India (NIXI).
    10. Thank You to Sponsors of ICANN 57 Meeting

      The Board wishes to thank the following sponsors:  CentralNic, Knipp Median und Communication GmbH, Afilias plc, Public Interest Registry, China Internet Network Information Center, Nominet, Web Werks India Pvt. Ltd., Radix FZC, Verisign, .blog, Directi Web Technology Private Limited, BNSL, Tata Tele Services, Atria Convergence Technologies Pvt. Ltd. (ACT) and GMR.
    11. Thank You to Interpreters, Staff, Event and Hotel Teams of ICANN 57 Meeting

      The Board expresses its deepest appreciation to the scribes, interpreters, audiovisual team, technical teams, and the entire ICANN staff for their efforts in facilitating the smooth operation of the meeting.
      The Board would also like to thank the management and staff of the Hyderabad International Convention Center for providing a wonderful facility to hold this event. Special thanks are extended to Vijay Ramnath Ugale, Event Manager; Varun Mehrotra, Director of Sales - Meetings & Events; Gorav Arora, Director of Sales and Marketing; Shyam Sunder, Director of Convention; Ravindra Reddy, Assistant Manager of Client Services; Johnet Pereira, Manager of Client Services; Rambabu Talluri, IT Manager; Anand Prakash Ravi, Operational Manager; Ramu Dasari, Asst. Manager of Client Services; Mr. Ranjan Alu, Asst. Manager F&B; Executive Chef Amanaraju; and Gilbert Yeo from Pryde Live.
  2. Main Agenda:

    1. Two-Character Domain Names in the New gTLD Namespace

      Whereas, Specification 5, Section 2 of the New gTLD Registry Agreement requires registry operators to reserve two-character ASCII labels within the TLD at the second level. The reserved two-character labels “may be released to the extent that Registry Operator reaches agreement with the related government and country-code manager of the string as specified in the ISO 3166-1 alpha-2 standard.  The Registry Operator may also propose the release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes, subject to approval by ICANN.”
      Whereas, the GAC has issued advice to the Board in various communiqués on two-character domains. The Los Angeles Communiqué (15 October 2014) stated, “The GAC recognized that two-character second level domain names are in wide use across existing TLDs, and have not been the cause of any security, stability, technical or competition concerns. The GAC is not in a position to offer consensus advice on the use of two-character second level domains names in new gTLD registry operations, including those combinations of letters that are also on the ISO 3166-1 alpha 2 list.”  The GAC also issued advice in the Singapore Communiqué (11 February 2015) and the Dublin Communiqué (21 October 2015).
      Whereas, on 16 October 2014, the Board directed ICANN to develop and implement an efficient procedure for the release of two-character domains currently required to be reserved in the New gTLD Registry Agreement, taking into account the GAC’s advice in the Los Angeles Communiqué on the matter. ICANN launched this procedure (the “Authorization Process”) on 1 December 2014.
      Whereas, as part of the Authorization Process, ICANN launched a community consultation process to help develop a standard set of proposed measures to avoid confusion with country codes. The measures were intended to be mandatory for new gTLD registries seeking to release reserved letter/letter two-character labels.
      Whereas, in the GAC’s Helsinki Communiqué (30 June 2016), the GAC advised the Board to “urge the relevant Registry or the Registrar to engage with the relevant GAC members when a risk is identified in order to come to an agreement on how to manage it or to have a third-party assessment of the situation if the name is already registered.”  The advice was incorporated in the proposed measures to avoid confusion.
      Whereas, on 8 July 2016, ICANN published for public comment the Proposed Measures for Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes, which listed measures registry operators could adopt to avoid confusion with corresponding country codes. The measures incorporated the GAC’s advice issued in the Helsinki Communiqué. Forty-three comments were submitted by individuals, governments and groups/organizations.
      Whereas, the Board considered the public comments, the staff summary and analysis report of public comments, and GAC advice. The proposed measures were updated to take into account the public comments and GAC advice relating to the proposed measures and two-character labels.
      Resolved (2016.11.08.15), the Measures for Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes as revised are approved, and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to authorize registry operators to release at the second level the reserved letter/letter two-character ASCII labels not otherwise reserved pursuant to Specification 5, Section 6 of the Registry Agreement, subject to these measures.

      Rationale for Resolution 2016.11.08.15

      Why the Board is addressing the issue?
      On 16 October 2014, the Board adopted a resolution directing staff to develop and implement an efficient procedure for the release of two-character domains currently required to be reserved in the New gTLD Registry Agreement, taking into account the GAC’s advice in the Los Angeles Communiqué on the matter.
      For nearly two and a half years, ICANN has been developing and implementing a procedure as directed by the Board. On 1 December 2014, ICANN launched the first phase of the procedure, an Authorization Process for Release of Two-Character ASCII Labels. The finalization of this procedure is the implementation of a framework containing standardized measures registry operators can implement to avoid confusion, in accordance with the Registry Agreement, and allow for the release of all letter/letter two-character ASCII labels corresponding with country codes not otherwise reserved pursuant to Specification 5, Section 6 of the Registry Agreement.
      The GAC has issued advice on this topic in various communiqués over the past two years including, most recently, the Helsinki Communiqué. Per Article XI, Section 2.1 of the ICANN Bylaws, the GAC may "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the policies.
      What is the proposal being considered?
      The proposal is to address requests from registry operators to release reserved letter/letter two-character ASCII labels and the advice from the GAC on reserved letter/letter labels. The Board is taking action to approve the Measures for Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes, as revised. By approving the revised measures, the Board is authorizing ICANN to issue a blanket authorization that allows new gTLD registry operators who implement the required measures to release all reserved letter/letter two-character ASCII labels not otherwise reserved pursuant to Specification 5, Section 6 of the New gTLD Registry Agreement. The current authorization process, whereby a registry operator submits an individual request subject to 60-day comment period and ICANN’s review of comments, will be retired.
      Which stakeholders or others were consulted?
      ICANN initiated multiple public comment periods and consulted with various stakeholders on this matter over a period of nearly two and a half years.
      From June through September 2014, ICANN staff initiated five public comment forums to obtain feedback from the community on the amendments that resulted from various RSEPs to implement the proposed new registry service of releasing from reservation two-character ASCII labels1 for 203 TLDs. Various members of the community submitted comments, including the At-Large Advisory Committee (ALAC), gTLD registry operators, the Brand Registry Group (BRG), INTA Internet Committee (INTA), the Business Constituency (BC), the Intellectual Property Constituency (IPC) and a registrar.
      Since 1 December 2014 at the launch of the Authorization Process for Release from Two-Character ASCII Labels, all authorization requests for letter/letter two-character ACII labels were subject to a comment period. Over 646 requests have been received under this process.
      Throughout the nearly two and a half years, ICANN notified 1) the GAC for amendments posted from June through September 2014 and 2) governments for requests under the Authorization Process since December 2014, when two-character requests from registry operators were posted for comment. The GAC had not submitted comments under the Public Comment Periods for the amendments to release two-character labels. Under the Authorization Process, the GAC had not submitted comments, but various individual governments submitted comments on requests.
      On 6 October 2015, ICANN corresponded with governments who previously submitted comments requesting that clarification of their comments be provided via a new comment form within 60 days; new comments were required to be submitted via the new comment form.
      On 25 February 2016, ICANN corresponded with registry operators requesting they provide proposed measures to avoid confusion with corresponding country codes in order to respond to governments’ confusion concerns within 60 days.
      On 8 July 2016, taking into consideration the inputs from governments and registry operators, ICANN published for public comment the Proposed Measures for Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes, which listed measures registry operators could adopt to avoid confusion with corresponding country codes and which incorporated the GAC’s advice issued in its Helsinki Communiqué. As part of the proposal, registry operators who adopt the measures would be authorized to release all letter/letter two-character ASCII labels not otherwise reserved in other sections of the Registry Agreement, and the current process would be retired. Forty-three comments were received, including comments from the RySG, the BRG, the IPC, the NCSG, LACTLD, various governments, ccTLD registry operators and gTLD registry operators.
      What concerns or issues were raised by the community?
      From the five public comment periods from 2014 on registry agreement amendments that resulted from RSEPs, the majority of the comments received were in favor of the release of two-character domain names.
      The arguments made in favor of the release of the two-character domain names included:
      • The introduction of two-character domain names would increase competition since the current restrictions hinder competition, in particular for the new gTLDs, which are competing with legacy TLDs that are allowed to offer such registrations. The current restrictions to the new gTLD registry operators create a discriminatory situation, which is contrary to the ICANN Bylaws Article II, Section 3 that provide for Non-Discriminatory Treatment of ICANN stakeholders.
      • The introduction of two-character domain names poses a limited risk of confusion, or no risk at all, as demonstrated by prior use of two-character domain names in existing TLDs.
      • The release of two-character domain names would provide opportunities for companies and brands to have tailored segmented domain names to connect with the public as well as provide localized content, thus expanding consumer choice and driving economic growth, in particular in developing countries.
      • There is uniform precedent regarding the release of two-character domain names in the history of relevant RSEP requests.
      • The release of country codes and names is allowed by the Applicant Guidebook.
      The arguments made in opposition to the release of the two-character domain names expressed two general concerns: the first concern is related to the general recognition and associated use of the two character domain names leading to user confusion or abuse; the second concern is how to specifically protect ccTLDs when country and territory names are newly formed.
      From the public comment forum for the Proposed Measures for Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes, which established a standard set of registry operator requirements to avoid confusion, comments indicated support for the release of two-character labels reserved pursuant to Specification 5, Section 2 of the New gTLD Registry Agreement overall, including comments of support from the NCSG, IPC and RySG among others. Comments noted that the Registry Agreement allows for two paths by which registry operators may release two-character labels: one path of agreement with the government and country-code manager, and a second path of ICANN approval.
      There was moderate support for the Proposed Measures to the extent the Proposed Measures allows for the release of two-character labels, including comments of support from the RySG and BRG among others. Comments that seem to generally support the Proposed Measures made specific suggestions about how the framework could be improved, such as noting that two of the three proposed measures (registration policy and post-registration investigation) pertained to confusion and suggesting one measure (exclusive availability pre-registration period) be made voluntary.
      Some commenters took the position that governments do not have special rights to two-character labels that correspond with country codes, and that the labels should be released as soon as possible. Conversely, some governments and ccTLD operators commented with objections to the release of two-character labels that correspond with country codes and took the position that government and/or ccTLD operator approval is required.
      Over the past two years, the GAC has issued advice through various communiqués and formal correspondence to ICANN. Members of the GAC have varying views on the topic. In the Los Angeles Communiqué (15 October 2014), the GAC stated, “The GAC recognized that two-character second level domain names are in wide use across existing TLDs, and have not been the cause of any security, stability, technical or competition concerns. The GAC is not in a position to offer consensus advice on the use of two-character second level domains names in new gTLD registry operations, including those combinations of letters that are also on the ISO 3166-1 alpha 2 list.” In the Helsinki Communiqué (30 June 2016), the GAC stated, “Some countries and territories have stated they require no notification for the release of their 2 letter codes for use at the second level. The GAC considers that, in the event that no preference has been stated, a lack of response should not be considered consent. Some other countries and territories require that an applicant obtains explicit agreement of the country/territory whose 2-letter code is to be used at the second level.”
      The Singapore Communiqué (11 February 2015) and Dublin Communiqué (21 October 2015) advised improvements to the process such as extending the comment period from 30 days to 60 days and working with the GAC Secretariat to address technical issues on the comment form. In both communiqués, the GAC advised that comments from relevant governments should be fully considered. In its Helsinki Communiqué, the GAC also advised the Board to “urge the relevant Registry or the Registrar to engage with the relevant GAC members when a risk is identified in order to come to an agreement on how to manage it or to have a third-party assessment of the situation if the name is already registered.”
      What significant materials did the Board review? What factors did the Board find to be significant?
      The Board reviewed several materials and also considered several significant factors during its deliberations about whether or not to approve the request. The significant materials and factors that the Board considered as part of its deliberations, included, but not limited to the following:
      Are there positive or negative community impacts? Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public? Are there any security, stability or resiliency issues relating to the DNS?
      The overall impact on the community is anticipated to be positive as new opportunities for diversification, competition and targeted content creation in the gTLD namespace are created, while minimal risk of user confusion has been identified.
      It is not expected that there will be any significant fiscal impact on ICANN.
      In December 2006, the Registry Services Technical Evaluation Panel (RSTEP) issued a report regarding the release of two-character labels and found that “taken in the context of our overall understanding, none of the observations point to the proposed release of two-character Second Level Domain having a material security or stability impact on the Internet.”  Additionally, these names are not reserved in many legacy TLDs, which have not caused apparent security, stability or resiliency issues in relation to the DNS.
      It is expected that the release of these names in new gTLDs will not cause security, stability or resiliency issues.
      Is this either a defined policy process within ICANN’s Supporting Organizations or ICANN’s Organizational Administrative Function decision requiring public comment or not requiring public comment?
      This is an Organizational Administrative Function for which public comments were received.
    2. Consideration of the Corn Lake, LLC v. ICANN Independent Review Process Final Declaration

      Whereas, on 19 October 2016, ICANN received the Independent Review Process (IRP) Final Declaration in the IRP filed by Corn Lake, LLC (Corn Lake) against ICANN (Final Declaration).
      Whereas, the IRP Panel declared that:  (i) Corn Lake’s challenges to the determination rendered by an expert panelist sustaining the Independent Objector’s (IO’s) Community Objection against Corn Lake’s application for .CHARITY (Expert Determination) and the Board Governance Committee’s (BGC’s) denial of Corn Lake’s Reconsideration Request 14-3 challenging the Expert Determination were time-barred; (ii) “the Board acted without conflict [of interest]”; and (iii) “the Board members exercised independent judgment, believed to be in the best interests of the community.”  (See Final Declaration, ¶¶ 7.14, 8.70, 8.74, https://www.icann.org/en/system/files/files/irp-corn-lake-final-declaration-17oct16-en.pdf.)
      Whereas, the Panel further declared that “the [Board] action of omitting .CHARITY from the [the review mechanism to address perceived inconsistent or unreasonable string confusion objection determinations (Final Review Procedure)] was inconsistent with the Articles of Incorporation and Bylaws.”  (Final Declaration at ¶ 11.1(b).)
      Whereas, the Panel further declared that “Claimant, Corn Lake, is the prevailing party” and that “no costs shall be allocated to the prevailing party.”  (Final Declaration at ¶¶ 11.1(a), (e).)
      Whereas, the Panel recommended that: (1) “the Board extend the [Final Review Procedure] to include review of Corn Lake’s .CHARITY Expert Determination”; and (2) “the Board continue to stay any action or decision in relation to [Spring Registry Limited’s] .CHARITY application until such time as the Board reviews and acts upon the opinion of the IRP Panel.”  (Final Declaration at ¶¶ 11.1(c)-(d).)
      Whereas, in accordance with Article IV, section 3.21 of ICANN’s Bylaws, the Board has considered the Final Declaration.
      Resolved (2016.11.08.16), the Board accepts the following findings of the Final Declaration:  (i) Corn Lake is the prevailing party in the Corn Lake, LLC v. ICANN IRP; (ii) Corn Lake’s challenges to the Expert Determination and the BGC’s denial of Corn Lake’s Reconsideration Request 14-3 were time-barred; (iii) the Board acted without conflict of interest; (iv) “the Board members exercised independent judgment, believed to be in the best interests of the community”; (v) “the [Board] action of omitting .CHARITY from the [Final Review Procedure] was inconsistent with the Articles of Incorporation and Bylaws”; and (vi) the parties shall each bear their own costs.
      Resolved (2016.11.08.17), the Board directs the President and CEO, or his designee(s), to take all steps necessary to implement the Panel’s recommendation that “the Board extend the [Final Review Procedure] to include review of Corn Lake’s .CHARITY Expert Determination.”
      Resolved (2016.11.08.18), the Board directs the President and CEO, or his designee(s), to refrain from taking any further action or decision in relation to Spring Registry Limited’s .CHARITY application until after the results of the Final Review Procedure are known, and then to proceed pursuant to established processes with the processing of both Corn Lake’s and Spring Registry Limited’s applications in accordance with the results of Final Review Procedure.

      Rationale for Resolutions 2016.11.08.16 – 2016.11.08.18

      Corn Lake, LLC (Corn Lake) initiated Independent Review Process (IRP) proceedings challenging:  (1) the determination rendered by an expert panelist sustaining the Independent Objector’s (IO’s) community objection against Corn Lake’s application for .CHARITY (Expert Determination); (2) the Board Governance Committee’s (BGC’s) denial of Corn Lake’s Reconsideration Request 14-3 challenging the Expert Determination; and (3) the Board’s decision to not include the Expert Determination in the review mechanism to address perceived inconsistent or unreasonable string confusion objection determinations (Final Review Procedure).
      Corn Lake applied to ICANN for the opportunity to operate the .CHARITY new gTLD.  Spring Registry Limited (“SRL”) also submitted an application for .CHARITY, and Excellent First Limited (Excellent First) submitted an application for .慈善 (the Chinese translation of “charity”).  ICANN’s Independent Objector (IO) filed Community Objections against the two .CHARITY applications, as well as the application for .慈善, meaning charity.  The IO was concerned that, among other things, the lack of any policy restricting registrations in these gTLDs to charitable or not-for-profit organizations created a likelihood of detriment to the rights or legitimate interests of the charity community, to users, and to the general public.  (See IO’s Community Objection at Para. 46, pgs. 16-17, http://www.independent-objector-newgtlds.org/home/the-independent-objector-s-objections/charity-cty-corn-lake-llc/).
      The International Centre for Expertise of the International Chamber of Commerce (ICC) expert panel evaluating the IO’s Community Objection to Corn Lake’s application rendered a determination (Expert Determination) in favor of the IO, finding that, because Corn Lake’s .CHARITY application did not include registration restrictions to charitable organizations, “there is a likelihood of material detriment to the charity sector community were the Application to proceed.”  The same ICC expert panel also evaluated the IO’s Community Objections to SRL’s application and Excellent First’s application, rendering determinations in favor of SRL and Excellent First Limited.  Specifically, the expert panel found that SRL’s and Excellent First’s commitments set out in their applications to restrict registrations in the applied-for string to charitable organizations was sufficient to negate any concern of material detriment to the targeted community.
      On 24 January 2014, Corn Lake filed Reconsideration Request 14-3 (Request 14-3) seeking reversal of the Expert Determination.  On 27 February 2014, the Board Governance Committee (BGC) denied Request 14-3, finding no evidence that the expert panel violated any process or policy in reaching its determination.
      Separately, in April 2013, the Governmental Advisory Committee (GAC) recommended in the Beijing Communiqué that the Board adopt eligibility restrictions for “sensitive strings,” including .CHARITY.  (See Beijing Communiqué at https://www.icann.org/en/system/files/correspondence/gac-to-board-11apr13-en.pdf.)  The New gTLD Program Committee (NGPC) adopted the GAC’s recommendation by a 5 February 2014 resolution (see https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-02-05-en), which, according to the Panel, effectively required that whichever applicant ultimately operated the .CHARITY gTLD would need to restrict registrations to charitable organizations.  Also at that 5 February 2014 meeting, the NGPC adopted a resolution that authorized the ICANN President and CEO to initiate a public comment period with respect to a proposed review mechanism to address perceived inconsistent string confusion objection determinations (Final Review Procedure).  At its creation, the Final Review Procedure was limited to the review of certain string confusion expert determinations for .CAR/.CARS, .CAM/.COM, and .SHOP/.ONLINESHOPPING (in Japanese characters).  In March 2014, via the public comment process, Corn Lake’s parent company (Donuts, Inc.) asked the Board to extend the Final Review Procedure to perceived inconsistent determinations of community objection, such as that concerning .CHARITY.  The Board did not do so when the procedure was implemented in a 12 October 2014 Board resolution (“12 October 2014 Resolution”). (See https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-10-12-en.)
      Corn Lake’s IRP Request, submitted on 24 March 2015, sought a declaration that the ICANN Board’s decision not to include the .CHARITY determination in the 12 October 2014 Resolution violates ICANN’s Articles and Bylaws, and also asked the Panel to review the Expert Determination and the BGC’s denial of Request 14-3.
      On 17 October 2016, the three-member IRP Panel (Panel) issued its Final Declaration, which was circulated to the parties on 19 October 2016.  After consideration and discussion, pursuant to Article IV, Section 3.21 of the ICANN Bylaws, the Board adopts the findings of the Panel, which are summarized below, and can be found in full at https://www.icann.org/en/system/files/files/irp-corn-lake-final-declaration-17oct16-en.pdf.
      The Panel held that the IRP request was denied in part and granted in part, and determined Corn Lake to be the prevailing party.  (Final Declaration at ¶¶ 7.14, 8.96, 11.1(a).)  As a threshold issue, the Panel declared that Corn Lake’s challenges to the Expert Determination and the BGC’s denial of Request 14-3 were “out of time” and therefore time-barred from consideration in this IRP.  (Final Declaration at ¶¶ 7.14, 8.34.)
      The Panel also declared that:  (i) with respect to setting filing deadlines, “ICANN is entitled and indeed required to establish reasonable procedural rules in its Bylaws, including in respect of filing deadline, in order to provide for orderly management of its review processes” (id. at ¶ 7.9); (ii) “it is now well established that: ‘…the IRP Panel is charged with ‘objectively’ determining whether or not the Board’s actions are in fact consistent with the Articles, Bylaws and Guidebook, which the Panel understands as requiring that the Board’s conduct be appraised independently, and without any presumption of correctness’” (id. at ¶ 8.18); (iii) “[t]here is no suggestion that the Board had a conflict of interest, and the IRP Panel finds that the Board acted without conflict.” (id. at ¶ 8.70); and (iv) “[t]here is no indication that the Board members were acting in any way other than in good faith and exercising independent judgment, with the subjective belief that they were acting in the best interests of the community.  The IRP Panel finds that the Board members exercised independent judgment, believed to be in the best interests of the community” (id. at ¶ 8.74).  The Panel further stated:  “[t]his IRP Panel does not suggest that ICANN lacks discretion to make decisions regarding its review processes as set out in the Applicant Guidebook, which may well require it to draw nuanced distinctions between different applications or categories of applications.  Its ability to do so must be preserved as being in the best interest of the Internet community as a whole.”  (Id. at ¶ 8.98).
      The Panel stated that “[t]he sole issue before this Panel is whether the Board properly or improperly excluded the .Charity Expert Determinations from the [Final Review Procedure] in the first place.”  (Final Declaration at ¶ 8.97, fn. 246.)  In considering this issue, the Panel noted that the Expert Determination was largely based on the fact that Corn Lake’s application originally had not made clear that it would restrict registrations to charitable organizations.  The Panel felt that the NGPC’s acceptance of the Beijing Communiqué created a “leveling effect,” effectively requiring that whichever .CHARITY applicant prevailed, it would be required to implement restricted registration policies.  The Panel noted:  “We make no finding that the Board’s failure to consider the impact of its adoption of the Beijing Communiqué recommendations was malicious or intentional.  We find simply that the leveling effect on the eligibility requirements in the pending applications of the new PIC requirement was a material fact that should have been considered, and apparently it was not.”  (Final Declaration at ¶ 8.73.)  The Panel therefore declared that that “the action of omitting .CHARITY from the [Final Review Procedure] was inconsistent with the Articles of Incorporation and Bylaws.”  (Final Declaration at ¶ 11.1(b).)  The Panel noted that its finding “is further supported by the ICANN Board’s [later] decision to include the .HOSPITAL Expert Determinations [in the Final Review Procedure], despite those Determinations appearing to have been less clearly within the criteria tha[n] the .CHARITY Determinations.”  (Final Declaration at ¶ 8.101.)  The Panel further noted that “this is a unique situation and peculiar to its own unique and unprecedented facts[; and t]his unique set of circumstances created what was doubtless a difficult situation for ICANN to consider in establishing the scope of the new review process[.]”  (Final Declaration at ¶ 8.97.)
      The Panel further declared that “these IRP proceedings involve extraordinary circumstances,” and therefore “no costs shall be allocated to the Claimant as the prevailing party,” “each Party shall bear its own costs in respect of this IRP Panel proceeding.”  (Final Declaration at ¶¶ 9.3-9.5.)
      In addition, the Panel recommended that: (1) “the Board extend the [Final Review Procedure] to include review of Corn Lake’s .CHARITY Expert Determination”; and (2) “the Board continue to stay any action or decision in relation to [Spring Registry’s] .CHARITY application until such time as the Board reviews and acts upon the opinion of the IRP Panel.”  (Final Declaration at ¶¶ 11.1(c)-(d).)  Subsequent to the issuance of the Final Declaration, the Board received a letter on 28 October 2016 (dated 27 October) from Corn Lake’s counsel “urg[ing] the Board to reinstate its .CHARITY application without” “[g]oing through the motions of such review[, which] will cost money to ICANN and Corn Lake, and unnecessary time for all .CHARITY applicants.”  Corn Lake requests that the Board “reinstat[e] Corn Lake’s .CHARITY application and allow[] it to compete for the domain without going through the additional time and expense [of the Final Review Procedure].”  (See https://www.icann.org/en/system/files/correspondence/genga-to-icann-board-27oct16-en.pdf.)  The Board had the opportunity to review Corn Lake’s correspondence and has taken it into consideration in reaching its Resolution regarding the Panel’s recommendation.
      As required, the Board has considered the Final Declaration.  As this Board has previously indicated, the Board takes very seriously the results of one of ICANN’s long-standing accountability mechanisms.  Accordingly, and for the reasons set forth in this Resolution and Rationale, the Board has accepted the Panel’s Final Declaration as indicated above.
      Adopting the Panel’s Final Declaration and implementing the Panel’s recommendation will have a direct financial impact on the organization, but that impact will not impact the underlying budget for FY17.  Adopting the Panel’s Final Declaration will not have any direct impact on the security, stability or resiliency of the domain name system.
      This is an Organizational Administrative function that does not require public comment.
    3. Thank You to the Global Multistakeholder Community

      Whereas, on 14 March 2014, the National Telecommunications and Information Administration (NTIA) of the United States Department of Commerce announced its intention to transition the stewardship of the IANA Functions to the global multistakeholder community.
      Whereas, NTIA asked ICANN to convene global stakeholders to develop a proposal to transition the current role, played by NTIA, in the coordination of the Internet's domain name system (DNS). NTIA required that the proposal for transition must have broad community support and uphold the following principles:
      • Support and enhance the multistakeholder model;
      • Maintain the security, stability, and resiliency of the Internet DNS;
      • Meet the needs and expectation of the global customers and partners of the IANA services; and,
      • Maintain the openness of the Internet.
      NTIA also stated it would not accept a proposal that replaces the NTIA role with a government-led or an inter-governmental organization solution.
      Whereas, in the Board resolutions 2016.03.10.12-15 the ICANN Board resolved to accept the IANA Stewardship Transition Coordination Group’s (ICG) IANA Stewardship Transition Proposal, reflecting he proposals developed by CRISP, IANA Plan and the CWG-Stewardship, and approve the transmittal of the Proposal to NTIA of the United States Department of Commerce in response to NTIA's 14 March 2014 announcement.
      Whereas, the Board further resolved that the President and CEO, or his designee, was directed to plan for the implementation of the Proposal so that ICANN is operationally ready to implement in the event NTIA approves of the Proposal and the IANA Functions Contract expires.
      Whereas, in its Board resolutions 2016.03.10.16-19, the ICANN Board resolved to accept the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) Work Stream 1 Report ("Report"), and approve the transmittal of the Report to NTIA to accompany the IANA Stewardship Transition Proposal developed by the ICG.
      Whereas, the Board further resolved that the President and CEO, or his designee, is directed to plan for the implementation of the Report so that ICANN is operationally ready to implement in the event NTIA approves of the IANA Stewardship Transition Proposal and the IANA Functions Contract expires.
      Whereas, on 27 May, the Board adopted resolution 2016.05.27.01-04, resolving that the New ICANN Bylaws will be deemed effective upon the expiration the IANA Functions Contract between ICANN and NTIA,   and directed the President and CEO, or his designee, to plan for the implementation of the Bylaws so that ICANN is operationally ready to    meet its obligations in the event NTIA approves of the IANA Stewardship Transition Proposal and the IANA Functions Contract expires.
      Whereas, on 9 June NTIA informed ICANN that NTIA had completed its review of the IANA Stewardship Proposal along with the other US agencies, and determined that the proposal meets the criteria set out by NTIA in March 2014 when it announced its intent to transition NTIA”s stewardship of key Internet domain name functions to the global multistakeholder community. NTIA noted and outlined in their report that there was still some work to be done before the IANA functions stewardship transition could occur, and requested that ICANN provide NTIA with an implementation planning status report by August 12, 2016.
      Whereas, on 12 August, ICANN provided NTIA with the implementation planning status report noting that: “ICANN, working   with the multistakeholder community, confirms that all required IANA   functions stewardship transition tasks specified in NTIA’s June 9, 2016 letter are complete, and all other tasks in support of the IANA    stewardship transition are either in a final review stage or awaiting      approval, which will be complete in advance of September 30, 2016 to allow the IANA functions contract to expire.”
      Whereas, on 1 October, the NTIA advised ICANN and the global     multistakeholder community that the IANA Functions contract had   expired.
      Resolved (2016.11.08.19), the Board expresses its deep appreciation for the tireless efforts of the global multistakeholder community, including the leadership of the various community-led groups contributing to the Proposals. The development of the coordinated      Proposals across the global community, that met the criteria set out    by NTIA, and the work to achieve implementation to allow for the    contract to lapse on 30 September 2016, is unprecedented and serves as an historical record of the success of the work of the community to achieve a longstanding goal.
      Resolved (2016.11.08.20), the Board expresses its deep appreciation to the US Department of Commerce, for standing by the long-standing commitment to end the IANA Functions contract, and for its   dedication, and tireless efforts as a partner with ICANN and the community to achieving this historic goal.
    4. Thank You to Bruno Lanvin for his service to the ICANN Board

      Whereas, Bruno Lanvin was appointed by the Nominating Committee to serve as a member of the ICANN Board on 21 November 2013.
      Whereas, Bruno Lanvin concluded his term on the ICANN Board on 8 November 2016.
      Whereas, Bruno served as a member of the following Committees:
      • Audit Committee
      • Finance Committee
      • New gTLD Program Committee
      • Organizational Effectiveness Committee [formerly the Structural Improvements Committee]
      Resolved (2016.11.08.21), Bruno Lanvin has earned the deep appreciation of the Board for his term of service, and the Board wishes him well in his future endeavors within the ICANN community and beyond.
    5. Thank You to Erika Mann for her service to the ICANN Board

      Whereas, Erika Mann was appointed to serve by the Nominating Committee as a member of the ICANN Board on 10 December 2010.
      Whereas, Erika concludes her term on the ICANN Board on 8 November 2016.
      Whereas, Erika has served as a member of the following Committees and Working Groups:
      • Audit Committee
      • Compensation Committee
      • Global Relationships Committee
      • Governance Committee
      • New gTLD Program Committee
      • Board-GAC Recommendation Implementation Working Group
      • Board Working Group on Internet Governance (BWG-IG)
      • Board Working Group on Registration Data Directory Services (BWG-RDS)
      • ICANN Board Liaison to the Charter Drafting Team for the Cross Community Working Group on New gTLD Auction Proceeds
      Resolved (2016.11.08.22), Erika Mann has earned the deep appreciation of the Board for her term of service, and the Board wishes her well in her future endeavors within the ICANN community and beyond.
    6. Thank You to Kuo-Wei Wu for his service to the ICANN Board

      Whereas, Kuo-Wei Wu was appointed by the Address Supporting Organization (AS0) to serve as a member of the ICANN Board on 22 April 2010.
      Whereas, Kuo-Wei concluded his term on the ICANN Board on 8 November 2016.
      Whereas, Kuo-Wei served as a member of the following ICANN Board Committees and Working Groups:
      • Global Relationships Committee
      • IANA Committee
      • New gTLD Program Committee
      • Organizational Effectiveness Committee [formerly the Structural Improvements Committee]
      • Public Participation Committee
      • Risk Committee
      • IDN Variants Working Group
      Resolved (2016.11.08.23), Kuo-Wei Wu has earned the deep appreciation of the Board for his term of service, and the Board wishes him well in his future endeavors within the ICANN community and beyond.
    7. Thank You to Suzanne Woolf for her service to the ICANN Board

      Whereas, Suzanne Woolf was appointed to serve by the Root Server System Advisory Committee (RSSAC) as a member of the ICANN Board on 5 December 2004.
      Whereas, Suzanne concludes her term on the ICANN Board on 8 November 2016.
      Whereas, Suzanne has served as a member of the following Committees and Working Groups:
      • Governance Committee
      • Risk Committee
      • IANA Committee
      • IDN Variants Working Group
      Resolved (2016.11.08.24), Suzanne Woolf has earned the deep appreciation of the Board for her term of service, and the Board wishes her well in her future endeavors within the ICANN community and beyond.
    8. Thank You to Bruce Tonkin for his service to the ICANN Board

      Whereas, Bruce Tonkin was appointed by the Generic Names Supporting Organization (GNSO) to serve as a member of the ICANN Board on 29 June 2007.
      Whereas, Bruce Tonkin concluded his term on the ICANN Board on 8 November 2016.
      Whereas, Bruce served as a member of the following Committees:
      • Governance Committee
      • Compensation Committee
      • Executive Committee
      • Risk Committee
      • Board Working Group on Registration Data Directory Services (BWG-RDS)
      • ICANN Board Liaison to the Cross Community Working Group (CCWG) on Enhancing ICANN Accountability
      Resolved (2016.11.08.25), Bruce Tonkin has earned the deep appreciation of the Board for his term of service, and the Board wishes him well in his future endeavors within the ICANN community and beyond.