Details
| Ref. Name: AFPUB-2018-GEN-002-DRAFT02 |
Versions: 2.0 Status: Withdrawn Obsoletes: CPM 3.0 - The Policy Development (PDP) |
Author: Jordi Palet Martinez jordi.palet at theipv6company.com The IPv6 Company
|
| Amends: CPM ar 3.0 | ||
| Submitted: 20 November 2018 |
Proposal
1.0 Summary of the problem being addressed by this proposal
The Policy Development Working Group (PDWG) discusses about the policy proposals and anyone may participate either in the Resource Policy Discussion mailing list (RPD) and the bi-annual Public Policy Meetings (PPM).
However, not all RPD participants are able to attend all the PPM, where the Chairs determine whether rough consensus has been achieved, so discrimination is generated towards those not able to attend, which usually are a much larger group.
With its requirement of face-to-face participation at the PPM, the current PDP might – at least partially – be the cause of the low levels of community participation in the process.
This proposal would simplify the process by not requiring participation at the in-person PPM to achieve consensus – instead, consensus would be determined balancing the mailing list and the forum – and would therefore increase community participation.
The proposal adapts all the timings consequently with the proposed changes, in order to make the process agile, and allow new proposals in a shorter period of time before the meeting (2 weeks). In summary, it requires that the discussion in the mailing list is done by a minimum of 8 weeks, before determining consensus. That time can longer because the need to present the proposal into a meeting.
So, there are two possible cases:
a) A proposal (or a new version) is submitted 8 weeks (or a longer period) before the PPM. Consensus will be determined by the chairs within a maximum of two weeks.
b) A proposal (or a new version) is submitted less than 8 weeks before the PPM.
Consensus will be determined by the chairs within a maximum of two weeks, once the 8 weeks of discussion time in the list ends.
The minutes timing is also adapted, as it seems unnecessary to wait for 3 weeks, if the consensus determination will be made in 2 weeks.
2.0 Summary of how this proposal addresses the problem
This simple proposal seeks to eliminate the requirement that states that consensus must only be reached at the PPM, adapt the relevant timings and at the same time, clarifies the definition of “consensus” and “last call”.
Some of the timings are also adjusted.
3. Proposal
Amending 3.0 of the CPM, as follows:
|
Current |
Proposed |
|
3.1.1 Definition of “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”. |
|
|
3.4.1 Draft Policy Proposal During the development of a policy, draft versions of the document are made available for review and comment by publishing them on the AFRINIC website and posting them to the rpd@afrinic.net mailing list. Each draft policy is assigned a unique identifier by AFRINIC and the AFRINIC website shall also contain the version history and the status of all proposals. The draft policy shall be available for review for at least four weeks before the next Public Policy Meeting. The author(s) shall make the necessary changes to the draft policy according to the feedback received. The Working Group Chair(s) may request AFRINIC to provide an analysis (technical, financial, legal or other), of the impact of the draft policy proposal.
A draft policy expires after one calendar year unless it is approved by the AFRINIC Board of Directors as a policy. The timeout period is restarted when the draft policy is replaced by a more recent version of the proposal. A draft policy can be withdrawn by the author(s) by sending a notification to the Resource Policy Discussion mailing list.
|
3.4.1 Draft Policy Proposal and Discussion Timing During the development of a policy, draft versions of the document are made available for discussion by publishing them on the AFRINIC website and posting them to the rpd@afrinic.net mailing list. Each draft policy is assigned a unique identifier by AFRINIC and the AFRINIC website shall also contain the version history and the status of all proposals. The draft policy shall be available for discussion for at least 2 weeks before the next Public Policy Meeting. The author(s) shall make the necessary changes to the draft policy according to the feedback received. AFRINIC will publish an impact analysis (technical, financial, legal or other) at least 10 days before the next Public Policy Meeting. A draft policy expires after 6 months, unless it is approved by the AFRINIC Board of Directors as a policy. The timeout period is restarted when the draft policy is replaced by a more recent version of the proposal. A draft policy can be withdrawn by the author(s) by sending a notification to the Resource Policy Discussion mailing list. A draft policy must be discussed on the Public Policy List a minimum of 8 weeks and maximum, the period of time required so it can be presented in the PPM. Consensus for a proposal can be determined only once it has been presented and discussed in the PPM. |
|
3.4.2 Public Policy Meeting The draft policy is placed on the agenda of an open public policy meeting. The agenda of the meeting shall be announced on the Resource Policy Discussion mailing list at least two weeks prior to the meeting. No change can be made to a draft policy within one week of the meeting. This is so that a stable version of the draft policy can be considered at the meeting. The Chair(s) determine(s) whether rough consensus has been achieved during the Public Policy Meeting.
The Chair(s) shall publish the minutes of proceedings of the Public Policy Meeting not later than three weeks after the meeting.
|
3.4.2 Public Policy Meeting and Consensus Determination The draft policy is placed on the agenda of an open public policy meeting. The agenda of the meeting shall be announced on the Resource Policy Discussion mailing list at least 1 week prior to the meeting. No change can be made to a draft policy within 1 week of the meeting. This is so that a stable version of the draft policy can be considered at the meeting. Once the minimum 8 weeks of discussion in the list and a presentation at the PPM are met, the Chair(s) have a maximum of 2 weeks to determine whether rough consensus has been achieved (considering both list and meeting). The Chair(s) shall publish the minutes of proceedings of the Public Policy Meeting not later than 2 weeks after the meeting. |
|
3.4.3 Last Call A final review of the draft policy is initiated by the Working Group Chair(s) by sending an announcement to the Resource Policy Discussion mailing list. The Last Call period shall be at least two weeks. The Working Group Chair(s) shall evaluate the feedback received during the Public Policy Meeting during this period and decide whether consensus has been achieved. |
3.4.3 Last Call A final discussion of the draft policy is initiated by the Working Group Chair(s) by sending an announcement to the Resource Policy Discussion mailing list. The Last Call period shall be 2 weeks. Within 1 week after the end of the last call, the Working Group Chair(s) shall confirm whether consensus is maintained. 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. |
4. Revision History
|
Date |
Details |
| 20 November 2018 |
Version 2: AFPUB-2018-GEN-002-DRAFT02 Addresses issues from Staff Assessment of version 1 |
|
23 October 2018 |
Version 1: AFPUB-2018-GEN-002-DRAFT01 Initial Draft Posted to rpd |
5. References
A similar proposal reached consensus in LACNIC (May 2018), has been implemented and has been used already for several months before the last policy meeting.