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

[rpd] [Community-Discuss] Update to Resources review policy proposal

Kevin Kamonye kevin.kamonye at gmail.com
Tue Nov 22 09:53:09 UTC 2016


It looks likes it is starting to sink in that v6 will eventually mean less
relevance for Afrinic and co.

​Kevin

On 22 November 2016 at 12:07, Saul Stein <saul at enetworks.co.za> wrote:

> Have I perhaps missed the point here, but what is the purpose of this
> policy?
>
> 1)      Is the purpose that there is no current way to reclaim resources
> fraudulently applied for?
>
> 2)      Preserve v4 space (but this policy would have to be for v6 too –
> I’d hate to have to audit all that space)
>
> 3)      To remove space that people are no longer using?
>
> 4)      Preserve v4 space?
>
>
>
> It is one thing saying that there is a need to audit, but for what
> purpose? And by purpose I am including the ultimate goal and objectives,
> since there is no point in saying lets audit and then there is no
> ramifications expect to AFRINIC earning less revenue from the resources it
> charges for.
>
>
>
> *From:* Badru Ntege [mailto:badru.ntege at nftconsult.com]
> *Sent:* 17 November 2016 07:09 AM
> *To:* Andrew Alston <Andrew.Alston at liquidtelecom.com>; Dewole Ajao <
> dewole at forum.org.ng>; sergekbk <sergekbk at gmail.com>; Arnaud AMELINA <
> amelnaud at gmail.com>; rpd >> AfriNIC Resource Policy <rpd at afrinic.net>
> *Subject:* Re: [rpd] [Community-Discuss] Update to Resources review
> policy proposal
>
>
>
>
>
>
>
>
>
> On 11/16/16, 1:43 PM, "Andrew Alston" <Andrew.Alston at liquidtelecom.com>
> wrote:
>
>
>
> So,
>
>
>
> I have a hypothetical question – and it will become a lot less
> hypothetical once I’ve run the numbers which I’m currently doing.
>
>
>
> Let’s say we implement this audit policy – and then – because we have to
> act consistently – we act against every member who is not announcing space
> because they cannot justify not announcing it – and we terminate their
> membership.
>
>
>
> Are the authors of this policy and those supporting it prepared to bear
> the cost of the fee increases that would be necessary to back fill the loss
> in revenue that would effectively bankrupt AfriNIC?  Running through the
> preliminary statistics – firstly the auditing process would be immensely
> expensive in HR cost – secondly – termination of members that aren’t
> “legitimately” announcing space by rough calculations could cost AfriNIC in
> excess of 15% of its revenue by the latest numbers available in the
> financial reports and correlating the unannounced space that is allocated
> with the billing file.
>
>
>
> I hardly believe that a drop in 15% of revenue would bankrupt AfriNIC ??.
>    If that’s the case then our problems are bigger than an Audit.  Which I
> definitely doubt.
>
>
>
> Lets not add scary variables to support opposition to a policy.
>
>
>
>
>
>
>
> Now, some would argue that is all the more reason to implement the audit
> policy – but here is a wake up call – the space you would recover in that
> call on those calculations – amounts to less than 10% of space that AfriNIC
> has allocated legitimately since May – so effectively, for the gain of
> looking tough and being rigid, we may end up bankrupting the organisation
> while recovering potentially a /15 worth of space.  Alternatively, from any
> logical business perspective – that money would have to be recovered from
> the members who are legitimately announcing space – because it certainly
> can’t just disappear.
>
>
>
> So, has anyone ACTUALLY thought through the implications of this policy?
> I remain firmly opposed.
>
>
>
> Andrew
>
>
>
>
>
> *From:* Dewole Ajao [mailto:dewole at forum.org.ng <dewole at forum.org.ng>]
> *Sent:* 16 November 2016 12:52
> *To:* sergekbk <sergekbk at gmail.com>; Arnaud AMELINA <amelnaud at gmail.com>;
> rpd >> AfriNIC Resource Policy <rpd at afrinic.net>; General Discussions of
> AFRINIC <community-discuss at afrinic.net>
> *Subject:* Re: [Community-Discuss] Update to Resources review policy
> proposal
>
>
>
> I think all policies (if we really intend to implement them) must be clear
> and leave no room for variable interpretation as ambiguity will put
> additional burdens of interpretation on staff.
>
> If the community's preference is for the 24-month window to become invalid
> on allocation/assignment of new resources, then the policy (proposal)
> should state it clearly; If on the other hand, the intention is for the
> 24-month window to stay in place come-what-may, it's better for the policy
> (proposal) to be explicit about it.
>
> Please see below, additional questions for the community to consider.
> Hopefully, they can be discussed and the authors can (if they so choose,)
> take the inputs from the community into their modified proposal.
>
> 3.3.2 Selected:
>
>
> A member is selected because of an internal report or due to a lack of
> contact between the AFRINIC and the member.
>
> Q1. Do we presently have an existing (effective) structure (apart from
> billing) that measures degree of contact with members?
> If there is no agreed means of measuring the degree contact, we need to
> define degrees of contact so that "lack of contact" (as referred to in the
> proposal) can be measured objectively.
>
> *Perhaps as a first step for ensuring regular contact without using up too
> many resources, this proposal might want to borrow a leaf from RIPE's
> Assisted Registry Check (ARC). See
> https://www.ripe.net/manage-ips-and-asns/resource-management/assisted-registry-check
> <https://www.ripe.net/manage-ips-and-asns/resource-management/assisted-registry-check>*
>
> *Basically, the RIR does a consistency check on members' Registry,
> Resource, and Route/rDNS information and then sends emails to the contacts
> on file showing their view. They then schedule a telephone call to work
> with the member and fix any identified issues. *
>
> *My understanding from RIPE is that these non-invasive checks sometimes
> reveal issues that may warrant more detailed investigation. The primary
> model is by random checks but done in a manner that checks every member at
> least once in 3 years (given the size of RIPE). They also have ARCs that
> are initiated as a result of information received from the member or third
> parties. *
>
> Q2. Can reachability/cooperation of a member for such a consistency
> check-and-fix activity as described above be used to measure the degree of
> contact?
>
> Q3. Given the fact that time taken for consistency checks are more
> predictable, can these be implemented as a preliminary step in addressing
> the "lack of investigation" problem as well as the concern about taking up
> much of members' and/or AFRINIC hostmasters' time?
>
> Regards,
> Dewole.
> (with apologies for continuing the cross-posting between RPD and
> Community-discuss)
>
> On 15/11/2016 20:18, sergekbk wrote:
>
> Hello Dewole,
>
>
> Thanks for this comment.
> The limit of 24 months applies to a member based on ressources
> portfolio.  If  the portfolio  changes with new allocation,   member can be
> audited  anytime on the new ressources if required.
>
> Is this clear enough or shall we make  it explicit  ?
>
> Kind Regards.
>
>
>
> *Serge Ilunga*
>
> *Cell: +243814443160*
>
> *Skype: sergekbk*
>
> *R.D.Congo*
>
> -------- Original message --------
>
> From: Dewole Ajao <dewole at tinitop.com> <dewole at tinitop.com>
>
> Date: 11/15/2016 11:38 (GMT+01:00)
>
> To: Arnaud AMELINA <amelnaud at gmail.com> <amelnaud at gmail.com>, "rpd >>
> AfriNIC Resource Policy" <rpd at afrinic.net> <rpd at afrinic.net>, General
> Discussions of AFRINIC <community-discuss at afrinic.net>
> <community-discuss at afrinic.net>
>
> Subject: Re: [Community-Discuss] Update to Resources review policy
> proposal
>
>
>
> Thanks for working to apply the community's input to your proposal,
> Arnaud.
>
> To test the proposed re-wording, consider the following sequence of events:
>
> Member XYZ initiates self-requested review;
> Review is completed by AFRINIC in X weeks;
> After review, Member XYZ applies for "large chunk" of number resources;
> Member XYZ receives "large chunk" of number resources in say 60 days;
> Member XYZ happens to make some unacceptable use of (previous or new)
> number resources and it somehow becomes known to the community;
> Regardless of convincing evidence, Member XYZ cannot be subjected to a
> review until 24 months have elapsed since the last review.
>
> Is this a design feature or a bug?
>
> Regards,
>
> Dewole.
>
>
>
> On 15/11/2016 10:48, Arnaud AMELINA wrote:
>
> Hi community !
> Following, recent discussions and in accordance with text proposal from
> Owen and others contributors, authors propose this as replacement to the
> section 3.3.3
>
> -'---old version---''
>
> 3.3.3 Reported: Here, members are reviewed either because:
>
> a. They have requested the review themselves or
> b. There has been a community complaint made against them that warrants
> investigation.
>
> ----new version-----
>
> 3.3.3 Reported: Here, members are reviewed either because:
>
> a..They have requested the review themselves or
> b. There has been a community complaint made against them that warrants
> investigation. Complaints shall be backed by evidence and AFRINIC  staff
> shall evaluate the facts as appropriate to conduct the review. However this
> review is not applicable to a member  on which a full review has been
> completed in the preceding 24 months.
>
> Regards.
>
> Arnaud.
>
>
>
>
>
> _______________________________________________
>
> Community-Discuss mailing list
>
> Community-Discuss at afrinic.net
>
> https://lists.afrinic.net/mailman/listinfo/community-discuss
>
>
>
>
>
> _______________________________________________ RPD mailing list
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20161122/9bc48701/attachment-0001.html>


More information about the RPD mailing list