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 12th Feb to discuss these proposals. Many participants expressed a supporting for the proposal. But a few opposing comments were expressed with concern that losing opportunities for remarks of APNIC members by losing consensus call at AMM. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年1月18日(金) 9:23 Bertrand Cherrier <b.cherr...@micrologic.nc>: > 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: > > - 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-v003: PDP Update > ------------------------------ > > Proposer: Jordi Palet Martínez > jordi.pa...@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 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”. > 2. Objective of policy change > > 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. > 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 > > 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”. > 5. Advantages / Disadvantages > > 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. > 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
* 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
