Dear SIG members
A new version of the proposal "prop-126: PDP Update"
has been sent to the Policy SIG for review.
Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-126/
You are encouraged to express your views on the proposal:
Please find the text of the proposal below.
Kind Regards,
Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs
prop-126-v003: PDP Update
Proposer: Jordi Palet Martínez
jordi.palet@theipv6company.com
With its requirement of face-to-face participation at the OPM, the
current PDP might – at least partially – be the cause of the low
levels of community participation in the process by using the
policy mailing list.
This proposal would allow an increased participation, by explicitly
considering also the comments in the list for the consensus
determination. So, consensus would be determined balancing the
mailing list and the forum, and would therefore increase
community participation.
Further, policy proposals are meant for the community as a whole,
and not only APNIC members, so this proposal suggest removing
the actual “double” consensus required in both groups.
Finally, it completes the PDP by adding a simple mechanism for
solving disagreements during an appeals phase and an improved
definition of ‘consensus’, as well as a complete definition of
the “consensus” and “last-call”.
To allow that consensus is determined also looking at the opinions
of community members that are not able to travel to the meetings,
adjust the time required before the relevant SIG to submit the
proposals, not requiring “double” consensus with the APNIC members
and facilitating a simple method for appeals.
The PDP is different in the different RIRs. This proposal is similar
to the RIPE PDP, possibly the region with the broadest participation
in its policy proposal discussions, although there are certain
differences such as the mandatory use of the mailing list and the
meeting, which is more similar to the PDP at ARIN (another region
with broad community participation). LACNIC has recently adopted
a similar policy proposal with the same aims.
Section 4. Proposal process
A policy proposal must go through the following chronological steps
in order to be adopted by APNIC.
Step 1
Actual:
Discussion before the OPM
A formal proposal paper must be submitted to the SIG mailing list and to
the SIG Chair
four weeks before the start of the OPM. The proposal must be in text
which clearly
expresses the proposal, with explicit mention of any changes being
proposed to existing
policies and the reasons for those changes. The APNIC Secretariat will
recommend a
preferred proposal format. If the four-week deadline is not met,
proposals may still
be submitted and presented for discussion at the meeting; however, no
decision may
be made by the meeting regarding the proposal. The proposal will need to
be resubmitted
in time for the following meeting if the author wishes to pursue the
proposal.
Proposed:
Discussion before the OPM
A formal proposal paper must be submitted to the SIG mailing list and to
the SIG Chair
four weeks before the start of the OPM.
The proposal must be in text which clearly expresses the proposal, with
explicit mention
of any changes being proposed to existing policies and the reasons for
those changes.
The APNIC Secretariat will recommend a preferred proposal format.
If the four-week deadline is not met, proposals may still be submitted
and presented
for discussion at the meeting; however, no decision may be made by the
meeting regarding
the proposal.
Step 2
Actual:
Consensus at the OPM
Consensus is defined as “general agreement” as observed by the Chair of
the meeting. Consensus
must be reached first at the SIG session and afterwards at the Member
Meeting for the process
to continue. If there is no consensus on a proposal at either of these
forums, the SIG (either
on the mailing list or at a future OPM) will discuss whether to amend
the proposal or to
withdraw it.
Proposed:
Consensus at the OPM
Consensus is defined as “rough consensus” as observed by the Chairs.
Consensus is determined in both, the SIG session and the SIG mailing
list, in a maximum of two
weeks after the OPM.
If there is no consensus on a proposal, the authors can decide to
withdraw it.
Otherwise, the proposal will expire in six months, unless a new version
is provided, following
the discussions with the community.
Step 3
Actual:
Discussion after the OPM
Proposals that have reached consensus at the OPM and the AMM will be
circulated on the appropriate
SIG mailing list for a period. This is known as the “comment period”.
The duration of the “comment
period” will be not shorter than four weeks and not longer than eight
weeks. The decision to extend
more than four weeks, including the duration of the extension, will be
determined at the sole
discretion of the SIG Chair.
Proposed:
Last-Call
Proposals that have reached consensus will be circulated on the
appropriate SIG mailing during four
weeks.
The purpose of the “last-call” is to provide the community with a brief
and final opportunity to
comment on the proposal, especially those who didn’t earlier.
Consequently, during this period editorial comments may be submitted
and, exceptionally, objections
if any aspect is discovered that was not considered in the discussion
prior to determining consensus.
Any new objections must also be substantiated and must therefore not be
based on opinions lacking
a technical justification.
Step 4
Actual:
Confirming consensus
Consensus is assumed to continue unless there are substantial objections
raised during the
“comment period”. When the “comment period” has expired, the appropriate
SIG Chair
(and Co-chairs) will decide whether the discussions on the mailing list
represent continued
consensus. If the Chair (and Co-chairs) observe that there are no
“substantial objections”
to the proposed policy, consensus is confirmed and the process continues
as outlined below
in Step 5. If it is observed that there have been “substantial
objections” raised to the
proposed policy, consensus is not confirmed and the proposal will not be
implemented.
The SIG will then discuss (either on the mailing list or in the SIG)
whether to pursue
the proposal or withdraw it.
Proposed:
Confirming consensus
In a maximum of one week, after the end of the “last-call”, the Chairs
will confirm whether
consensus is maintained and the process continues as outlined below in
Step 5.
If it is observed that there have been “new substantial objections”
raised to the proposed
policy, consensus is not confirmed and the proposal will not be implemented.
The authors can decide to withdraw it, or provide a new version,
following the discussions
with the community. The proposal will expire in six months, unless a new
version is provided.
Step 5
Actual:
Endorsement from the EC
The EC, in their capacity as representatives of the membership, will be
asked to endorse the consensus
proposals arising from the OPM and the SIG mailing lists for
implementation at the next EC meeting. In
reviewing the proposals for implementation, the EC may refer proposals
back to the SIG for further
discussion with clearly stated reasons. As per the APNIC By-laws, the EC
may, at its discretion, refer
the endorsement to a formal vote of adoption by the APNIC members.
Proposed:
Endorsement from the EC
The EC, in their capacity as representatives of the membership, will be
asked to endorse the consensus
proposals arising from the OPM and the SIG mailing lists for
implementation at the next EC meeting.
In reviewing the proposals for implementation, the EC may refer
proposals back to the SIG for further
discussion with clearly stated reasons. As per the APNIC By-laws, the EC
may, at its discretion,
refer the endorsement to a formal vote of adoption by the APNIC members.
Appeals process
In case of disagreement during the process, any member of the community
must initially bring the matter
to the mailing list for consideration by the Chairs.
Alternately, if any member considers that the Chairs have violated the
process or erred in their judgement,
they may appeal their decision through the EC, which must decide the
matter within a period of four weeks.
Definition of “Rough Consensus”
Achieving “rough consensus” does not mean that proposals are voted for
and against, nor that the number of
“yes's”, “no's” and “abstentions” – or even participants – are counted,
but that the proposal has been
discussed not only by its author(s) but also by other members of the
community, regardless of their
number, and that, after a period of discussion, all critical technical
objections have been resolved.
In general, this might coincide with a majority of members of the
community in favor of the proposal,
and with those who are against the proposal basing their objections on
technical reasons as opposed to
“subjective” reasons. In other words, low participation or participants
who disagree for reasons that
are not openly explained should not be considered a lack of consensus.
Objections should not be measured by their number, but instead by their
nature and quality within the
context of a given proposal. For example, a member of the community
whose opinion is against a proposal
might receive many “emails” (virtual or real) in their support, yet the
chairs might consider that the
opinion has already been addressed and technically refuted during the
debate; in this case, the chairs
would ignore those expressions of support against the proposal.
For information purposes, the definition of “consensus” used by the RIRs
and the IETF is actually that
of “rough consensus”, which allows better clarifying the goal in this
context, given that “consensus”
(Latin for agreement) might be interpreted as “agreed by al”’
(unanimity). More specifically, RFC7282,
explains that “Rough consensus is achieved when all issues are
addressed, but not necessarily accommodated.”
Consequently, the use of “consensus” in the PDP, must be interpreted as
“rough consensus”.
Advantages:
Fulfilling the objectives above indicated and making sure that there is
no discrimination with community
members that aren’t able to travel.
Disadvantages:
None foreseen.
None.
http://www.lacnic.net/679/2/lacnic/policy-development-process
https://www.ripe.net/publications/docs/ripe-710