ICANN ICANN Email List Archives

[soac-newgtldapsup-wg]


<<< Chronological Index >>>    <<< Thread Index >>>

[soac-newgtldapsup-wg] Re: v6 non-universality (was: Comments On Draft text)

  • To: "<ebw@xxxxxxxxxxxxxxxxxxxx> <ebw@xxxxxxxxxxxxxxxxxxxx>" <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Subject: [soac-newgtldapsup-wg] Re: v6 non-universality (was: Comments On Draft text)
  • From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
  • Date: Tue, 2 Aug 2011 19:43:49 +0000


On 2 Aug 2011, at 15:39, <ebw@xxxxxxxxxxxxxxxxxxxx>
 <ebw@xxxxxxxxxxxxxxxxxxxx> wrote:

> Michele,
> 
> I didn't write, nor have I read, the text you are commenting on.

It's on the wiki:

https://community.icann.org/display/jaswg/IPv6


As for the ISP comment, yes - not all locations / countries on the planet are 
currently IPv6 reachable. Taking Africa as an example:
http://bgpmon.net/weathermap.php?inet=6&focus=africa

However it's not clear if it is impossible for them to have an IPv6 connection 
or not .. 

Several years ago when we first decided that we would deploy IPv6 we had to ask 
our upstream providers to switch it on and then we had to announce the prefixes 
etc., 

The upstream providers aren't going to push their downstream to adopt IPv6 .. 

> You wrote:
> 
>> There should NOT be an IPv6 exemption for "qualified" applicants.
> 
> Could you share with me your impression of the consequence of there
> being a requirement in the DAG, manditory at the point of transition
> to delegation?

Basically my view is very very simple. Either everyone has to have IPv6 or it's 
optional for everyone.

The wording in the DAG from my reading of it does not seem to be overly onerous 
- some parts of the IPv6 requirement are based on there being "demand"


> 
> My impression is that if an applicant's available infrastucture is
> not v6 provisioned earlier than one year after Staff's offer to
> contract that the offer will expire.
> 
> Now I could be mistaken, but this appears to limit the physical
> venue of registry backend siting to those with hard provisioning
> dates prior to 1Q14.

And why should that matter?

Geographic diversity is a key part of a stable registry, isn't it? 

> 
> I'm not trying to convince you of anything, but if we assume,
> just for the purposes of discussion, that some place, Nairobi
> perhaps, isn't currently scheduled by any one, let alone two,
> path independent v6 transit providers, but Cape Town is, that
> applications which propose Nairobi as an operations venue be
> either (a) determined not to be qualified for support, or (b)
> determined to be qualified for support, with the prior knowledge
> that ICANN legal staff will at a later date, approximately 1Q14,
> allow the offer to enter into contract expire?

If they know in advance that they intend to use a base which isn't IPv6 
reachable then shouldn't they look at using a second site which is or choose 
one which is reachable via v6?



> 
> Do you propose outcome (a) or outcome (b) or is there some other
> outcome(s) which you are proposing?
> 
> For comparision, an identical application proposing Cape Town
> as its operational venue, which is v6 provisioned, would both
> be currently qualified and prospectively qualified, unless for
> some reason v6 service is withdrawn by the v6 transit providers
> currently provisioning Cape Town.
> 
> If you perceive anything in this question insulting or belittling
> or deliberately obscure or written for some purpose other than
> understanding what you think v6-mandatory-to-contract-at-delegation
> means in practice, please ignore this note.
> 
> Eric

Regards

Michele

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.mobi/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 1 4811 763
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy