[arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure?

[Leo Bicknell]

It look me a while to parse all of this, because much of the original
mail looked like greek to me.  I'm afraid that may be the case for
many others on the list.  Let me try and connect some dots at a
really high level.

ICANN continues to look at new gTLD's in a process way to detailed
to get into in this forum.  Point is, think .bank, .Coke, or .XXX,
or any other new non-country code TLD.

A subgroup, the "JAS Working Group" is looking at part of the problem,
it's charter is at
http://gnso.icann.org/drafts/draft-jas-wg-charter-12may10-en.htm.

If I am parsing it correctly the idea is to identify people who
ICANN thinks should have a gTLD, but who may not be able to "make
a gTLD happen" all on their own.  This is a wide ranging task,
inlcuding things like folks who should have a gTLD but can't afford
the fees (and thus, fee wavers) to folks who don't really have the
technical expertise to run a gTLD, and may need help from ICANN to
make it happen in a technically correct way.

The most recent milestone report outlining all of this is here:
http://icann.org/en/topics/new-gtlds/jas-milestone-report-11nov10-en.pdf

I think page 15 is where things get relevant to this list, everything
I've written above and before that in the report is simply background
for this partciular issue.  The working group said there is full
concensus that

  "The following kinds of technical support are identified for those
   applicants that meet the criteria established for support:

   ...

   Infrastructure for providing support for IPv6 compatible solutions,
   e.g. hardware and networks as needed;"

Now, back to the original comment...

In a message written on Tue, Dec 21, 2010 at 07:55:36PM -0500, Eric Brunner-Williams wrote:
> My concern is that new registry proposants who meet the criteria for 
> assistance under the current JAS WG Milestone [1], or future work 
> product of the JAS WG, are, under the current ICANN Draft Applicant 
> Guidebook, required to be v6 capable. This is a cost that can be 
> deferred, if 123 becomes ARIN policy, at least for the ARIN region, 
> and if imitated by the other RIR's, more broadly.

This is where I get lost.  Policy proposal 123, as written, would
allow folks deploying gTLD's to get IPv4 number resources from a
reserved pool.  It in fact says nothing about IPv6 resources, they
are available today and will continue to be available in the future
on the exact same terms.

If the ICANN and/or the JAS WG has a requirement for IPv6 services than
Proposal 123 is totally unrelated as it deals with IPv4 resources.

If the concern is that some new gTLD's will try and use the resources
available under Proposal 123 to deploy IPv4 _only_ support for
gTLD's that is an administrative matter for ICANN and the JAS WG.
Indeed, even without this pool gTLD's could obtain IPv4 resources
from their upstream, via hosting companies, or even via the transfer
market.  This Proposal 123 may make it a bit easier for them, but
in no way is IPv4 impossible without it.

More to the point.  If a new gTLD operator comes online during the
transition I think it is in the best interest of the gTLD operator,
ICANN, ARIN, and the Internet at large that they have an IPv4 presense.
One cannot consider deploying an IPv6 only gTLD until a substantial
number of users have IPv6 services otherwise it would be crippled.

Which leaves me utterly confused by the original comments.  I can't
see how this hurts ICANN, the gTLD process, or the JAS WG in any
way, in fact it appears to me this proposal should make it easier
and operationally better to roll out new gTLD's.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101222/dcb445fa/attachment.sig>