Re: [soac-newgtldapsup-wg] On the v6 requirement

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

On 12/23/10 10:17 AM, Evan Leibovitch wrote:
> This is good news. Thanks, Eric.
If the rational for the v6 requirement is to ensure that applicants 
have an operational necessity for v6 arising from v4 exhaustion, then 
the rational is adequately addressed by the availability of PI CI 
space during a transition period of three or so years.
If the rational for the v6 requirement is to ensure some other goal, 
and one I've encountered several times is "to ensure that the next 
billion users, who will be only on v6 address provisioned devices, 
will be able to ...", then the availability of PI CI space is 
irrelevant, as are the existing resources on the existing v4 assets 
(the web as it currently exists, independent of what name spaces are 
available to provide names to the resources) and the existing users.
> So If I get this straight -- one of the DAG changes we can suggest
> (for suitable applicants) is a waiver from the contractual requirement
> of operating in "post-exhaustian" mode.
If the first rational is why the v6 requirement is in the DAG, then 
yes, and the waiver is for some reasonable transition period, and so 
not a cause for disqualification prior to delegation, or during the 
transition to delegation period. The request for PI CI space can be 
"supported by ICANN" for the qualified applicants, and wealthier 
applicants are free to simply buy v4 assets in the transfer market, or 
make a request for PI CI space independently.
> For practical reasons I'm trying to separate out the generic toolkit
> from required DAG changes.
We still need to get the real rational. If it is "v6 evangelicalism" 
then there is no hope -- the evangelicals, whether of DNSSEC or v6 or 
other quite arbitrary requirements not imposed upon any existing 
registry prefer failure for those not convinced of their beliefs. If 
it is operational prudence, then a means to be prudent while deferring 
v6 implementation and the associated costs is available, if 123 is 
adopted by the RIRs which serve more developing economies than ARIN does.
Eric

> - Evan
>
>
>
> On 23 December 2010 09:29, Avri Doria <avri@xxxxxxx
> <mailto:avri@xxxxxxx>> wrote:
>
>
>     Hi,
>
>     Sounds good.
>
>     Will this be formalized in an ARIN policy statement?  And does
>     this need to go through their  policy approval process?
>
>     a.
>
>     On 23 Dec 2010, at 08:51, Eric Brunner-Williams wrote:
>
>      >
>      > Colleagues,
>      >
>      > Yesterday I was able to obtain support from ARIN for new gTLD
>     operators to be able to receive post-exhaustion provider
>     independent address space from the reserve proposed for Criticial
>     Infrastructure (CI).
>      >
>      > While this does not assist any new gTLD operator demonstrate
>     the v6 requirement that is in the DAG, it reduces the possible
>     impulse for the contractual requirement, which is imposed as early
>     as when the application is submitted (and "frozen"), or as late as
>     the transition to delegation, if that impulse is that new gTLD
>     registries must be able to operate in a post-v4-exhaustion
>     environment.
>      >
>      > Whether the v6 requirement is relaxed from an unconditional
>     requirement, or made conditional upon the purpose of the applicant
>     and therefore the presumed address capability of the registrars,
>     registrants, and name-to-address resolving users, the access to CI
>     reserved resources is something that needs-qualified applicants
>     will benefit by, and not have to purchase provider independent v4
>     address assets in the transfer market, or settle for provider
>     dependent v4 address assets as a tenant of a hosting operator,
>     registry technical services provider, or competitor.
>      >
>      > One more tool in the assistance toolkit. Post-v4-exhaustion PI
>     blocks reserved for CI.
>      >
>      > The proposal is ARIN-prop-123. Reserved Pool for Critical
>     Infrastructure.
>      >
>      > Next, making the same request to the other regional registries
>     -- RIPE, APNIC, AfriNIC, LACNIC.
>      >
>      > Eric
>      >
>
>
>
>
>
> --
> - Evan