[AfriNIC-rpd] Pushing IPv6

[Mark Elkins]

Don't think she said that at all. What did catch my ears was that by
pushing IPv6 - they were able to target people who had not even been
aware of IPv6. Thus, the process became educational - hence why I'd like
to see something similar in our region.

I'd just like to take it a step further - and use it as a stick (once
the carrot has been taken).

AfriNIC may not have a mandate to decide what our membership is using -
but as a person who is watching the business side - I don't want to see
ISP's fail because somehow they got left in the cold.

As to how far the space is actually used - I don't mind too much. Maybe
this could be the straw that pushes the LIR into using IPv6, there are
probably concerned engineers in the LIR who'd love to play but their
requests have been reaching deaf ears. This turns IPv6 into a business
case - the LIR has to get IPv6 (step 1) - and use it (step 2) - or get
no more IPv4..

On Fri, 2011-11-25 at 13:30 +0000, rbiramah at ipi9.com wrote:
> Sofia, should we understand that you keep allocating IPv6 prefixes to a
> member even the previous this member received are not being used? 
> 
> Raz BIRAMAH
> iPi9
> GABON
> 
> Sent from my BlackBerry® smartphone
> 
> -----Original Message-----
> From: Sofía <sofia at lacnic.net>
> Sender: rpd-bounces at afrinic.net
> Date: Fri, 25 Nov 2011 08:53:20 
> To: <rpd at afrinic.net>
> Subject: Re: [AfriNIC-rpd] Pushing IPv6
> 
> Dear all,
> 
> I just wanted to clarify that we are not "pushing" anyone and that we
> are not "dictating to Members how to run their networks". The proposals
> I mentioned (LAC-2011-02 and LAC-2011-3.
> http://www.lacnic.net/en/politicas/propuesta-politicas.html) just
> establish that the applicant has to request an IPv6 block in case they
> don't already have one.
> 
> The proposal that applies to additional requests says that if the
> applicant already has an IPv6 block, they have to send us a report
> explaining what they are doing with IPv6, but we won't reject any
> request in case the report says "we are not doing anything". At least
> they will take a few minutes to think about it when writing this report.
> 
> Kind regards,
> 
> Ing. Sofía Silva Berenguer
> PGP Key ID: 0xAAD4EB5F
> Registration Services Area
> LACNIC - www.lacnic.net
> Latin American and Caribbean Internet Address Registry
> 
> El 24/11/11 15:03, Douglas Onyango escribió:
> > Mark,
> > If i get you right, then this policy would be:-
> > 1. Requiring Members applying for v4 to apply for and be
> > allocated/assigned v6 blocks as well
> > 2. Requiring members to (somehow) demonstrate usage of their v6 blocks.
> > 
> > Borrowing from my experience authoring the IPv4 Softlanding Policy,
> > where similar ideas were advanced, i would say this would be
> > "dictating to Members how to run their networks..." - To use the exact
> > words used at the time.
> > 
> > Now, unless the community's take on this has changed, I remember these
> > points bringing alot of contention to the said Policy with the only
> > option being for us to remove the whole tying v4
> > allocation/assignment/usage to v6 (or the reverse) out of the Policy.
> > 
> > So going  by the Community's feel at the time (which i doubt has
> > changed much), i wouldn't say this makes sense....But maybe i am wrong
> > on the community's perspective.
> > 
> > Regards,
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd

-- 
  .  .     ___. .__      Posix Systems - (South) Africa
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4007 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20111125/89f7de57/attachment.bin>