Another scratchpad post — this time about what a “get ready for new gTLDs” project might look like. I’ll try to write these thoughts in a way that scales from your own organization up to world-wide.
I’m doing this with an eye towards pushing this towards ICANN and new-gTLD applicants and saying “y’know, you really should be leading the charge on this. This is your ‘product’ after all.” Maybe we could channel a few of those “Digital Engagement” dollars into doing something useful? You know, actually engage people? Over a real issue? Just sayin’
Here we go…
Why we need to do this
- Impacts of the arrival of some new gTLDs could be very severe for some network operators and their customers
- There may not be a lot of time to react
- Progress on risk-assessment and mitigation-planning is poor (at least as I write this)
- Fixes may not be identified before delegation
- Thus, getting ready in advance is the prudent thing to do
- We benefit from these preparations even if it turns out we don’t need them for the new gTLD rollout
The maddening thing is, we may not know what’s really going to happen until it’s too late to prepare — so we may have to make guesses.
New gTLD impacts could be very broad and severe, especially for operators of private networks that were planned and implemented long before new gTLDs were conceived of. ISPs and connectivity providers may be similarly surprised. Click HERE to read a blog post that I wrote about this — but here are some examples:
- Microsoft Active Directory installations may need to be renamed and rebuilt
- Internal certificates may need to be replaced
- Long-stable application software may need to be revised
- New attack vectors may arise
- And so forth…
The key point here is that in the current state of play, these risks are unknown. Studies that would help understand this better are being lobbied for, but haven’t been approved or launched as I write this.
A “get ready” effort seems like a good idea
Given that we don’t know what is going to happen, and that some of us may be in a high-risk zone, it seems prudent to start helping people and organizations get ready.
- If there are going to be failures, preparedness would be an effective way to respond
- The issues associated with being caught by surprise and being under-prepared could be overwhelming
- “Hope for the best, prepare for the worst” is a strategy we often use to guide family decisions — that rule might be a good one for this situation as well
- Inaction, in the face of the evidence that is starting to pile up, could be considered irresponsible.
Looking on the bright side, it seems to me that there are wide-ranging benefits to be had from this kind of effort even if mitigation is never needed.
- We could improve the security, stability and resiliency of the DNS for all, by making users and providers of those services more nimble and disaster resistant
- If we “over prepare” as individuals and organizations, we could be in a great position to help others if they encounter problems
- Exercise is good for us. And gives all factions a positive focal point for our attention. I’ll meet you on that common ground.
Here’s a way to define success
I’m not sure this part is right, but I like having a target to shoot at when I’m planning something, and this seems like a good start.
- Minimize the impact of new-gTLD induced failures on the DNS, private and public networks, applications, and Internet users.
- Make technical-community resources robust enough to respond in the event of a new-gTLD induced disruption
- Maximize the speed, flexibility and effectiveness of that response.
Who does what
This picture is trying to say “everybody can help.” I got tired of adding circles and connecting-lines, so don’t be miffed if you can’t find yourself on this picture. I am trying to make the point that it seems to me that ICANN and the contracted parties have a different role to play than those of us who are on the edge, especially since they’re the ones benefiting financially from this new-gTLD deal.
Note my subtle use of color to drive that home. Also note that there’s a pretty lively conversation about who should bear the risks.
How do we get from here to there? If I were in complete command of the galaxy, here’s a high level view of how I’d break up the work.
As I refine this Gantt chart, it becomes clear to me that a) this is something that can be done, but b) it’s going to take some planning, some resources and (yes, dearly beloved) some time. Hey! I’m just the messenger.
We should get started
So here you are at the end of this picture book and mad fantasy. Given all this, here’s what I’d do if this puzzler were left up to me.
And here are the things I’d start doing right away:
- Agree that this effort needs attention, support and funding
- Get started on the organizing
- Establish a focal point and resource pool
- Broaden the base of participation
- Start tracking what areas are ready, and where there are likely to be problems
There you go. If you would like this in slide-deck form to carry around and pitch to folks, click HERE for an editable Powerpoint version of this story. Carry on.
Disclaimer: While the ICANN community scrambles to push this big pile of risk around, everybody should be careful to say where they’re coming from. I’m a member of the ISPCP constituency at ICANN, and represent a regional IXP (MICE) there. I don’t think this issue generates a lot of risk for MICE because we don’t provide recursive resolver services and thus won’t be receiving the name-collision notifications being proposed by ICANN staff. I bet some of our member ISPs do have a role to play, and will be lending a hand.
I am also a first-generation registrant of a gaggle of really-generic domain names. New gTLDs may impact the value of those names but experts are about evenly divided on which way that impact will go. I’m retired, and can’t conceive of how I’ll be making money from any activity in this arena.