<div dir="ltr"><div>Hi David Conrad,</div><div><br></div><div>Please see my replied as below.</div><div class="gmail_extra"><div class="gmail_extra"><div><div><div><div></div></div></div><div><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 6:16 PM, Karmann Olumomo <span dir="ltr"><<a href="mailto:karmann.olumomo@gmail.com" target="_blank">karmann.olumomo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div><div><table cellpadding="0"><tbody><tr><td><table cellpadding="0"><tbody><tr><td><h3><span name="David Conrad">David Conrad</span> <span><span><</span><a href="mailto:drc@virtualized.org" target="_blank">drc@virtualized.org</a><span>></span></span> </h3></td></tr></tbody></table></td><td><div><span><img title="signature.asc" alt="Attachments" src="https://mail.google.com/mail/images/cleardot.gif"></span><span title="Mon, Oct 27, 2014 at 2:22 AM" alt="Mon, Oct 27, 2014 at 2:22 AM">Oct 27 (10 days ago)</span><div style="outline:0px"><span><img alt="" src="https://mail.google.com/mail/images/cleardot.gif"></span></div></div></td><td></td><td rowspan="2"><div><img alt="" src="https://mail.google.com/mail/images/cleardot.gif"></div><div><img alt="" src="https://mail.google.com/mail/images/cleardot.gif"></div></td></tr><tr><td colspan="3"><table cellpadding="0"><tbody><tr><td><div><font color="#777777"><br></font></div></td></tr></tbody></table></td></tr></tbody></table></div><div></div><div></div><div></div><div></div><div><div style="overflow:hidden"><p>Karmann,<br><br> Some personal opinions:<br><span><br> On Oct 26, 2014, at 9:26 AM, Karmann Olumomo <<a href="mailto:karmann.olumomo@gmail.com" target="_blank">karmann.olumomo@gmail.com</a>> wrote:<br>> 1) Summary of the Problem Being Addressed by this <span><font color="#222222" style="background-color:rgb(255,255,204)">Policy</font></span> Proposal<br>> <br>> Some member are experiencing extreme long wait for their additional allocation request to get passed, some members are experiencing none technical information requested from <span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span>(customer data, marketing channel etc), in order to improve overall service quality of <span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span>, here is the <span><font color="#222222" style="background-color:rgb(255,255,204)">policy</font></span>.<br>> <br>> 2) Summary of How this Proposal Addresses the Problem<br>> <br>> To improve overall service quality and transparency of <span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span>’s number resource services by documenting roles and responsibilities of <span><font color="#222222" style="background-color:rgb(255,255,204)">AFRINIC</font></span>.<br>> 3) Proposal<br>> <br>> 1.<span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span> should make decision on subsequent allocation requests based on <span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span>   <span><font color="#222222" style="background-color:rgb(255,255,204)">policy</font></span>, and conclude a request no longer than the 20% of the total period AFRNIC approves the resources for. (E.g. If <span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span> is issuing resources to its member to meet its 12 months needs, the longest waiting time for <span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span> allocation process should not be longer than 20%*12month, to cope with 80% utilization requirement for additional allocation). If <span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span> 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.<br><br></span>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.<br><br> 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.<br><br> Note that I suspect if request processing time is being impacted by load, this will only get worse as the additional <span><font style="background-color:rgb(255,255,204)">policy</font></span> requirements the community is putting (or is proposing to put) on staff implies increased work in reviewing requests.<br><span><br><font color="#ff9900">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.</font></span></p><p><span></span><br></p><p><span>>   2.<span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span> should publish standardized base information request for each typical type of resource allocation.<br><br></span>I disagree.<br><br><span><font style="background-color:rgb(255,255,204)">AfriNIC</font></span> 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 <span><font style="background-color:rgb(255,255,204)">AfriNIC</font></span> staff to do the investigations <span><font style="background-color:rgb(255,255,204)">policy</font></span> demands, I believe staff are going to need to be able to ask whatever questions they feel are necessary.<br><span><br>> 3.<span><font color="#222222" style="background-color:rgb(255,255,204)">Afrinic</font></span> should not store, request any marketing or business related none-technical information from its member, for example, customer data, marketing channel, and marketing budget.<br><br></span>I disagree.<br><br> One of the ways in which you catch folks lying is because it is actually hard to be consistent when lying.  If <span><font style="background-color:rgb(255,255,204)">AfriNIC</font></span> 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.<br></p><span><p><br></p><font color="#ff9900"><p>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.</p></font></span></div></div></div></div></blockquote><div> </div><div> </div><div>Best regards,</div><div>Karmann Olumomo</div></div></div></div></div><br></div></div>