[AfriNIC-rpd] AfriNIC Policy Proposal: Policy Development Process

[JORDI PALET MARTINEZ]

Hi Vincent,

See below.

Regards,
Jordi




> De: Vincent Ngundi <vincent at kenic.or.ke>
> Responder a: <vincent at kenic.or.ke>
> Fecha: Tue, 3 Jul 2007 13:11:20 +0300
> Para: <jordi.palet at consulintel.es>, AfriNIC Resource Policy Discussion List
> <rpd at afrinic.net>
> Asunto: Re: [AfriNIC-rpd] AfriNIC Policy Proposal: Policy Development Process
> 
> Hi Jordi,
> 
> See my comments inline.
> 
> [...]
>> 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.
>> 
>> [Jordi] If you want to make it really redundant, I will suggest to
>> make it 3
>> members in 3 years terms, being renewed at a different timing. It
>> will mean
>> that the first 2 seats, the first term will last only 1 and 2 years,
>> respectively. This ensures that even if 2 folks fail, you still
>> have one
>> (plus the staff member). Also it helps to distribute the load of
>> different
>> proposals among the MG. Also you need to indicate something that if
>> one of
>> the MG members has a policy proposal, he needs to be excluded of
>> chairing
>> the meeting/emails discussions were that proposal is being
>> discussed and he
>> can't participate in the consensus achievement decision.
> 
> 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.

> 
> (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 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.

The process needs very precise definitions, including timelines. Otherwise
becomes vague and not only not-useful but even contra productive.

> 
>> 2. Policies can be proposed in two ways:
>>  (a) Directly by the author
>> 
>> [Jordi] I guess you mean directly to the list, because they are always
>> "directly by the author/s"
> 
> Yes, thank you.
> 
> "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.
>> 
>> [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.

> 
>> [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 !

> 
>> 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
>> <%22mailto:rpd@>  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 chair to
>> determine
>> whether there is consensus or not.
>> 
>> [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.

> 
>> 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.

> 
>> 7. A last call for comments on the policy will be announced on the
>> policy
>> mailing list. A period of 15 days will be given for the community
>> to suggest
>> any final changes and amendments. If there is consensus during the
>> Last-Call, 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] The last call should be started the day after the consensus is
>> achieved either in the mailing list (for non-objections, or in the f2f
>> meeting). I guess you mean here "go to step 8 below".
>> 
>> [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.
>> 
>> 8. If there is consensus 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 RPD Moderator Group (MG) to the Board.
>> 
>> [Jordi] I guess you mean PDP.
> 
> yes, thanks.
> 
>> 
>> Note: The policy should be ratified by the BoT at the subsequent Board
>> Meeting.
>> 
>> [Jordi] I will say "non-later than 30 days after the last call ends
>> and
>> implemented in a maximum of 60 days after the BoT ratification".
> 
> I agree.
> 
>> [Jordi] There should be a clear definition of what it means
>> discussing a
>> policy. As the policies are already review by the MG before going
>> into the
>> mailing list, it is assumed that they are CONFORMING with the PDP.
>> Consequently, any discrepancy about a policy not being subjected to
>> the PDP,
>> can't be raised publicly, instead in case of doubt, it should be
>> brought
>> privately to the MG for their consideration. This avoids the
>> manipulation of
>> the process. For example, somebody can say "this is against the
>> IETF" (which
>> never is the case, as the PDP is NOT subjected to IETF and the
>> community can
>> jump over IETF decisions if deemed necessary) and many people could
>> decide
>> because that comment against the policy. Moreover, if somebody made
>> publicly
>> such statement ("you can't do that because doesn't follow the PDP")
>> that
>> participant should be excluded of the mailing list and
>> participation in the
>> meetings for 180 days. If he persist in his attitude, should be
>> excluded
>> again for twice that time, and so on.
> 
> I think the PDP is open and as such we should ensure that all
> comments by members are made in an open, public platform (like the
> mailing list of the open public policy meeting). IMHO, I don't think
> members should be punished for airing their views.

When a comment try to manipulate the process, should be avoided. Even if the
chair say something like "this is not correct, that statement is not fair
with the policy and should be ignored, because it is not true that the
policy is against the PDP", the community is already impacted and they may
have a different opinion about the policy and will not "think about it the
same way". We have seen this already, so it must be avoided at all means !
Having the MG reviewing the policy ensures that this is not going to happen,
but if someone still try to manipulate the process it should be banned. It
is not a punishment, is making sure that it is avoided to happen again.

> 
> -v




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.