Re: [sig-policy] Version 4 of prop-126 PDP Update
Dear Colleagues,
I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-126, based
on a meeting we organized on 21th Aug to discuss these proposals.
Many participants expressed a supporting for the proposal with reasons
that discussions in the mailing list will be reflected more than ever,
also with the reason that expiring policy of the proposal at Step 4
sound good both author and community.
And a few question were expressed as below:
- In Step2, it seems difficult to understand the process. Which is correct?
1. Consensus is determined...
Firstly SIG mailing list/other electronic means/the SIG session
and then
Member Meeting
2. Consensus is determined...
Firstly SIG mailing list/other electronic means
and then
SIG Session
Afterward
Member Meeting
- What is "other electronic means" ? Is it CONFER?
If it is CONFER, I am concerned that CONFER does not know the exact
number of people who voted.
Best Regards,
Satoru Tsurumaki
JPOPF-ST
2019年8月9日(金) 3:14 Sumon Ahmed Sabir <sasabir@gmail.com>:
>
>
> Dear SIG members
>
> A new version of the proposal "prop-126: PDP Update" has been sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> 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:
>
> - Do you support or oppose the proposal?
> - Is there anything in the proposal that is not clear?
> - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> ----------------------------------------------------------------------
>
> prop-126-v004: PDP Update
>
> ----------------------------------------------------------------------
>
> Proposer: Jordi Palet Martínez
> jordi.palet@theipv6company.com
>
>
> 1. Problem Statement
> --------------------
>
> 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
> 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.
>
> Even if this is actually done by the chairs, it is not part of the
> actual PDP,
> and thus constitutes a very clear and explicit violation of the PDP and
> the risk
> is that anyone from the community could appeal any decision based on that.
>
> 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”.
>
>
> 2. Objective of policy change
> -----------------------------
>
> To allow that consensus is determined formally looking at the opinions
> of community
> members that are not able to travel to the meetings and facilitating a
> simple method
> for appeals.
>
>
> 3. Situation in other regions
> -----------------------------
>
> 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.
>
>
> 4. Proposed policy solution
> ---------------------------
>
> Current Text
> Step 2: 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.
>
> New Text
> Step 2: Consensus Determination
> Consensus is defined as “rough consensus” as observed by the Chairs.
>
> Consensus is determined first considering the SIG mailing list, other
> electronic means,
> and the SIG session, and afterwards at the Member Meeting.
>
> 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,
> restarting the discussions with the community.
>
> ==================================================
>
> Current Text
> Step 3: 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.
>
>
> New Text
> Step 3: Last-Call
> Proposals that have reached consensus at the OPM and the AMM 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.
>
> ===================================================
>
> Current Text
> Step 4: 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.
> 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.
>
>
> New Text
> Step 4: 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.
>
> ====================================================
>
> 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”.
>
>
> 5. Advantages / Disadvantages
> -----------------------------
>
> Advantages:
> Fulfilling the objectives above indicated and making sure that there is
> no formal discrimination with
> community members that aren’t able to travel.
>
> Disadvantages:
> None foreseen.
>
>
> 6. Impact on resource holders
> -----------------------------
>
> None.
>
>
> 7. References
> -------------
> http://www.lacnic.net/679/2/lacnic/policy-development-process
> https://www.ripe.net/publications/docs/ripe-710
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy