Hi Jordi,
Inline:
(a) see my comments.
(b) a redraft of the policy
-v
[...]
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
people.
see redraft.
(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.
ditto.
[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
the
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
(for
example 30 days for nomination, at least 120 days before the
following
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.
ditto.
The process needs very precise definitions, including timelines.
Otherwise
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
proposal
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
proposal.
The deadline for submitting a proposal (30 days before the meeting)
counts
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
doesn't
conform to the AfriNIC PDP. This should be the only and clear
exception.
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
resources,
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
on this.
[...]
[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
objective
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
objection".
No, there need to be NOW a clear definition about what it is
consensus,
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
reached
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
mailing
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
much
better than meetings and should be that way (look for example IETF,
never
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
meetings.
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
call,
otherwise, go to step 4.
see redraft.
[...]
-v
#####################
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.
Proposed Policy
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
[email protected] 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
the policy.
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
minimum information
- 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'
ratification.
Effect on AfriNIC
This policy will affect the current Policy Development Policy.
#####################
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
