Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

Re: [rpd] Afrinic policy proposal—Afrinic Service guild lines

Lu Heng h.lu at anytimechinese.com
Fri Nov 21 05:41:51 UTC 2014


Hi

My allocation has been told that under board decision for past 2 month.

Since I have confirmed with NRO as well as few other RIRs, including but
not limit to Lacnic and Apnic staff during past meetings, Board should not
interfere with allocation process at all.

And for whom ask about how and why we used up our allocation--simple
reply--none of your business.

with regards.

Lu



On Thu, Nov 6, 2014 at 2:48 AM, Karmann Olumomo <karmann.olumomo at gmail.com>
wrote:

> Hi David Conrad,
>
> Please see my replied as below.
>
> On Wed, Nov 5, 2014 at 6:16 PM, Karmann Olumomo <karmann.olumomo at gmail.com
> > wrote:
>
>> David Conrad <drc at virtualized.org>
>> [image: Attachments]Oct 27 (10 days ago)
>>
>> Karmann,
>>
>> Some personal opinions:
>>
>> On Oct 26, 2014, at 9:26 AM, Karmann Olumomo <karmann.olumomo at gmail.com>
>> wrote:
>> > 1) Summary of the Problem Being Addressed by this Policy Proposal
>> >
>> > Some member are experiencing extreme long wait for their additional
>> allocation request to get passed, some members are experiencing none
>> technical information requested from Afrinic(customer data, marketing
>> channel etc), in order to improve overall service quality of Afrinic,
>> here is the policy.
>> >
>> > 2) Summary of How this Proposal Addresses the Problem
>> >
>> > To improve overall service quality and transparency of Afrinic’s
>> number resource services by documenting roles and responsibilities of
>> AFRINIC.
>> > 3) Proposal
>> >
>> > 1.Afrinic should make decision on subsequent allocation requests based
>> on Afrinic   policy, and conclude a request no longer than the 20% of
>> the total period AFRNIC approves the resources for. (E.g. If Afrinic is
>> issuing resources to its member to meet its 12 months needs, the longest
>> waiting time for Afrinic allocation process should not be longer than
>> 20%*12month, to cope with 80% utilization requirement for additional
>> allocation). If Afrinic was not able to make decision on a certain
>> request within this period, for each additional month beyond this period,
>> the requesting member should receive percentage of the requested period of
>> the total request until such decision has been made, in order to protect
>> member from smooth running of its business.
>>
>> Having once worked at an RIR, I can say that trying to put processing
>> time limits is fine as long as there are sufficient resources to permit the
>> processing. However, if the request load is outstripping the ability for
>> staff to process that load, adding processing time limits will make things
>> worse.
>>
>> I would recommend asking staff for more information regarding processing
>> times of all additional allocation requests (I'd actually recommend a
>> public dashboard-style website showing aggregate request processing time
>> statistics) and, if there appear to be consistent delays, asking staff for
>> a root cause analysis and a mitigation plan.
>>
>> Note that I suspect if request processing time is being impacted by load,
>> this will only get worse as the additional policy requirements the
>> community is putting (or is proposing to put) on staff implies increased
>> work in reviewing requests.
>>
>> To be honest I don't understand why there would be delaying for the new
>> requirements, every delayed number will effect the business and so I
>> believe setting a time frame for the new additional allocation requests is
>> needed. It is better from a business perspective and protecting business
>> from smooth running and servicing the internet in the region is the
>> essential goal of any RIR.
>>
>>
>> >   2.Afrinic should publish standardized base information request for
>> each typical type of resource allocation.
>>
>> I disagree.
>>
>> AfriNIC staff are being placed in a position of being investigators,
>> trying to discover if a requester is lying to them about their need, where
>> they are located, what they intend to do with the address space, etc.
>> While a base set of information requesters can be expected to provide would
>> be useful, if the community expects AfriNIC staff to do the
>> investigations policy demands, I believe staff are going to need to be
>> able to ask whatever questions they feel are necessary.
>>
>> > 3.Afrinic should not store, request any marketing or business related
>> none-technical information from its member, for example, customer data,
>> marketing channel, and marketing budget.
>>
>> I disagree.
>>
>> One of the ways in which you catch folks lying is because it is actually
>> hard to be consistent when lying.  If AfriNIC staff is going to be in
>> the investigatory business, they need to look at what a requester told them
>> in the past and compare it to what they're telling them now and ask
>> questions when there is significant deviation.
>>
>>
>> I believe members wont agree to disclose their  customer data, marketing
>> channel etc etc to other party  because above information supposed to be
>> confidential. Plus most likely this business must involved with NDA.I just
>> think this policy is contradiction and disclosing such data to third party,
>> regardless the reason, are most likely not legal in most of country due to
>> the privacy law.
>>
>
>
> Best regards,
> Karmann Olumomo
>
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
>


-- 
--
Kind regards.
Lu

This transmission is intended solely for the addressee(s) shown above.
It may contain information that is privileged, confidential or
otherwise protected from disclosure. Any review, dissemination or use
of this transmission or its contents by persons other than the
intended addressee(s) is strictly prohibited. If you have received
this transmission in error, please notify this office immediately and
e-mail the original at the sender's address above by replying to this
message and including the text of the transmission received.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20141121/4cde4f5c/attachment.html>


More information about the RPD mailing list