[rpd] New Proposal - "Internet Number Resources Audit by AFRINIC (AFPUB-2016-GEN-001-DRAFT01)"

[Mark Elkins]

I also agree with Tim (and Saul).

Firstly, AFRINIC works on a slow start principal, the first
allocation/assignment is usually small - so there would be little
wastage due to non-growth.

After that, any new application requires a check on previous
applications - that the ISP has reached a certain percentage of
utilisation. I'm aware that when Andrew at Liquid Telecom asked for more
space the Hostmaster folk at AFRINIC really made him work hard, jumping
through loops. I have full trust in the AFRINIC staff. ;-)

If someone stops paying, resources are reclaimed - which satisfies me
with what happens when a Member goes out of business.

I'm not aware that any other RIR has a similar policy - not that we
should not be able to come up with original ideas in our Region - but
this does suggest that its probably not a good idea. They have already
run dry, so would have been able to look at this possibility before now.

The thought that occurs to me is one of re-arranging the deckchairs with
the IPv4 ship already resting on the sea floor. Fun for SCUBA Divers -
but that's about it.

I'd rather hear that ISP's have deployed IPv6, at least on all
externally facing services including all DNS, E-Mail and WEB Services.

I do not believe that anyone who has not yet deployed IPv6 as per above
can morally support this proposal - they have not done their bit.
And if they have, they will realise that this policy adds very little value.

I do not support this Policy.


On 23/05/2016 10:45, Saul Stein wrote:
> I agree with McTim.
> If the member is in breach of the RSA, then membership criteria should
> deal with that.
> If a member applies and received resources, there are conditions
> attached and need to be adhered to and the terms and conditions of the
> agreement should deal with any breached.   IF and only if that process
> is broken, should we look at fixing it, but not by putting other
> processes in place to fix other issues! 
> 
> Is there perhaps an real example of an issue that needs to be solved here? 
> 
> Regards
> Saul
> 
> On 22 May 2016, at 18:06, McTim <dogwallah at gmail.com
> <mailto:dogwallah at gmail.com>> wrote:
> 
>> All,
>>
>>
>>
>> On Sat, May 21, 2016 at 3:53 AM, Seun Ojedeji <seun.ojedeji at gmail.com
>> <mailto:seun.ojedeji at gmail.com>> wrote:
>>
>> <snip>
>>  
>>
>>
>>     Section 4 of the Registration Service Agreement (RSA) provides the
>>     framework for investigations of the usage of allocated Internet
>>     Number resources, defines members’ obligation to cooperate and the
>>     measures to be taken by AFRINIC in case of failure to comply.
>>
>>
>> If the above is the case, why is this policy needed?
>>
>>  
>>
>>
>>     The lack of such investigation or regular control can lead to
>>     inefficient usage of the Internet Number resources, to stockpiling
>>     and other types of abuse.
>>
>>
>> Is there any evidence to support this statement??
>>
>>
>> I tend to agree with Mr. Alston, it seems to me to be  "impractical".
>>
>> It would impose significant costs on the organisation to an end which
>> is already at our disposal.
>>
>>
>>
>> -- 
>> Cheers,
>>
>> McTim
>> "A name indicates what we seek. An address indicates where it is. A
>> route indicates how we get there."  Jon Postel
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>> https://lists.afrinic.net/mailman/listinfo/rpd
> 
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
> 

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4230 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20160523/13278de9/attachment.p7s>