Search RPD Archives
[AfriNIC-rpd] AfriNIC Policy Proposal: Policy Development Process
vincent at kenic.or.ke
Wed Jul 4 22:11:09 UTC 2007
(a) see my comments.
(b) a redraft of the policy
>> I agree partly.
>> (a) I had come up with the following but wanted to see the comments
>> from the members first.
>> We have 2 members for a 3-year term. The first for 2 years and the
>> second for 3 years. The AfriNIC staff member will complement the two.
> I think any decision is better if you have 3 than just 2 people.
> The staff
> should not "vote" on the MG decisions. This is what you have in
> APNIC and
> RIPE NCC. In ARIN is even more complex, I think a total of 12-15
>> (b) About excluding a member of the MG from chairing if they propose
>> a policy, I think that would be a good idea though there would still
>> be a loophole. What if the MG member asks someone else to propose the
>> policy on their behalf? I think this will be an issue of ethics.
> You've no way to control this thru the PDP, as you say is a
> personal ethic
> problem. Hopefully we aren't in that situation, but even in that case,
> having 3 MG members makes is more difficult to the "hidden-
> proponent" than
> having just 2.
>>> [Jordi] No need to nominate/elect them in a f2f meeting, in fact I
>>> will say
>>> this should be avoided, because that means that the first meeting
>>> elected candidates will not have time to prepare the meeting and
>>> work with
>>> the authors of the proposals, which is very important. The
>>> process of
>>> electing them should be described also, with a concrete timeline
>>> example 30 days for nomination, at least 120 days before the
>>> meeting, ten 30 days for election). At this way you give 60 days
>>> for the
>>> elected folks to work with the authors.
>> I still think the community (or the board) should propose names and a
>> decision reached at via consensus. If need be, then we can make
>> amendments to process. I don't think there's need for such an
>> elaborate process right now.
> The board is the AfriNIC board, so they have nothing to say here.
> They only
> represent to the members (and this is why they only ratify the
> policies, as
> a way to confirm the "trust" of the process, nothing else). The PDP
> is for
> the community as a whole. So it should be the community who ask for
> volunteers and/or nominations.
> The process needs very precise definitions, including timelines.
> becomes vague and not only not-useful but even contra productive.
I suggest we get some more input from the community on this.
>>> (b) Through the Moderator Group (MG) which would assist a member
>>> of the
>>> community in drafting the text for the proposed policy.
>>> [Jordi] May be is good to ensure that they are always proposed thru
>>> the MG,
>>> as in other regions (3 out of 5, becoming 4 out of 5 in a similar
>>> in LACNIC), in order to ensure correction and applicability of the
>>> policy. I
>>> will say that the MG can't reject a policy proposal, just need to
>>> make sure
>>> that it is correct in grammar, understandability, etc. You need to
>>> say also
>>> how much time (I will say maximum a week) the MG has to review a
>>> The deadline for submitting a proposal (30 days before the meeting)
>>> from when the proposal is submitted to the MG.
>> I think we should give members the liberty to choose how they want to
>> propose their policies. It will also reduce the amount of work for
>> the MG. I don't think all members require the help of the MG to draft
>> a policy.
> In most of the cases the MG work for this will be to read the
> policy in the
> next 7 days and accept the submission. I think is a MUST to provide
> uniformity, grammar check (done by the staff I guess), verification of
> having a "readable" proposal and to allow the avoidance of the process
> manipulation that I have indicated below.
I suggest we get some more input from the community on this.
>>> [Jordi] the MG could reject a policy proposal ONLY in the case it
>>> conform to the AfriNIC PDP. This should be the only and clear
>> IMHO, a policy proposal should be rejected during the PDP not before
>> it has been submitted to the list. Otherwise, it would have been
>> rejected outside the PDP.
> But if a policy proposal try to make something against the PDP, or
> if the
> policy proposal is not related to the management of the AfriNIC
> or anything like that, you need to have an immediate way-out,
> instead of
> wasting community resources !
I still think the community should be given the opportunity to decide
>>> [Jordi] I will say that you need to measure "no major objection".
>>> The MG
>>> co-chairs (not the chair) need to determine the consensus in an
>>> way, and there should be an appeal process in case it is evident
>>> that the
>>> consensus measurement across different policies is not fair.
>> I think we should leave this to the co-chairs. We can at least ensure
>> that both co-chairs agree on whether consensus has been reached or
>> not. IMHO, consensus means "general agreement" or "no major
> No, there need to be NOW a clear definition about what it is
> otherwise it becomes more and more subjective and can change
> depending on
> the co-chairs, their humor on that day, etc.
please suggest something then the we can all consider it.
>>> 6. If there is consensus at the open policy meeting, go to step 7
>>> below. If
>>> there is not consensus, step 4 will be repeated until consensus is
>>> or the policy proposal is abandoned (or withdrawn)
>>> [Jordi] There should be a process to reach consensus without the
>>> need of a
>>> f2f meeting. For example, if there is no objection at all in the
>>> list. This facilitates minor issues to avoid waiting for a meeting.
>> I don't think the mailing list we have has matured enough to
>> represent the entire AfriNIC community. However, let's see what other
>> members say.
> On the other way around. The mailing list represents the community
> better than meetings and should be that way (look for example IETF,
> decisions taken in meetings, or RIPE NCC, or other RIRs that
> measure both
> the room and the list consensus). Remember that always there will
> be more
> people able to participate in the mailing list than able to attend
Yes, I agree with you on the convenience of the mailing list as a
means by which a majority of the community can participate. But my
point is that currently, we don't have a relatively high level of
participation on the list and as such the mailing list cannot be used
solely to determine the community's view.
I took the liberty to come up with the (average) number of people who
participate on the different RIR policy mailing lists. Please note
that some (read "_more than 10, save for the LACNIC list") of the
people are regular contributors to all the other mailing lists.
AfriNIC ~ 34
ARIN ~ 50
RIPE ~ 59
APNIC ~ 19
LACNIC ~ 29
I still think we _need policies to be discussed during the f2f meetings.
>>> [Jordi] It is not clear to me what it means "final changes and
>>> amendments" I
>>> will say that only editorial issues should be accepted in the last
>>> otherwise, go to step 4.
Name : Vincent Ngundi
Organisation : Kenya Network Information Center - KeNIC
Policy Affected : Policy Development Process
Date : 3rd July 2007
Proposal : Policy Development Process
Policy Term : Permanent
Incentive: The initial policy development process used by AfriNIC was
meant to be a transitional process. Now that AfriNIC has been well
established, it is being proposed to revise the policy development
process to increase participation from the community in the process.
The proposed policy development process (PDP) is described below:
1. A PDP Moderator Group (MG) will be set-up to moderate and
coordinate the policy development process and discussions. It will
consist of two members of the community. One AfriNIC staff will also
be providing support to the MG.
Note: The two(2) Moderator Group (MG) members will be nominated by
the community during a face-to-face (f2f) open public policy meeting
for a defined period.
The two (2) MG members shall be nominated for a 3-year term. The
first for 2 years and the
second for 3 years. AfriNIC will nominate one of it's staff members
to the MG.
2. Policies can be proposed in two ways:
(a) Directly to the list by the author
(b) Through the Moderator Group (MG) which would assist a member of
the community in drafting the text for the proposed policy.
Note: Policies can be proposed by anyone from the community.
3. The proposed policy is then posted on the mailing list
rpd at afrinic.net or any other appropriate mailing list. The mailing
list is open to anyone from the community at all times, and anyone
can join the list for discussion
4. The policy is discussed on the mailing list and amended
accordingly following the discussions.
5. After at least 30 days of discussion and comments on the mailing
list, the policy is brought to the public open policy (face-to-face)
meeting for a final round of discussions before the community
endorses or rejects the policy through consensus.
Note: Consensus is defined as general agreement of the group and is
not measured by a majority. It will be the onus of the MG co-chairs
to determine whether there is consensus or not.
6. If there is consensus at the open policy meeting, go to step 7
below. If there is not consensus, step 4 will be repeated.
7. A 15-day last call for comments on the policy will be announced on
the policy mailing list. During this 15-day period, comments agreed
upon during the open public policy meeting will be incorporated into
8. After the 15 days, the Moderator Group will send a report to the
AfriNIC Board of Trustees (BoT) which should contain the following as
- The date of the proposal
- Short summary of the online discussions
- Short summary of the face to face (f2f) discussions
- Short summary of the Last-Call period
- A recommendation of the PDP Moderator Group (MG) to the Board.
Note: The policy should be ratified by the BoT at the subsequent
Board Meeting which should be held no later than 30 days after the
last-call ends and implemented within 60 days after the BoTs'
Effect on AfriNIC
This policy will affect the current Policy Development Policy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the RPD