[rpd] Proposal to alter AFRINIC Policy Development Process

Wed May 9 16:01:40 UTC 2018

Policy Development Process Bis might just continue to go round in circles as consensus may never be reached. I think that the policy can be amended and adopted by section. This would in a long run give the PDWG a clearer view of ALL objections raised so they can be objectively addressed.This in my opinion would yield a more concise and focused version of this draft policy. Thank you
Oluwaseun 

  On Sun, May 6, 2018 at 1:09 PM, Mark Elkins<mje at posix.co.za> wrote:   I like what you have written. I do though think that some policies can
be agreed upon when there is zero objections to a particular policy -
usually something that is technical, simple and makes common sense
(thinking of no reverse delegation when the nameservers are broken - a
policy under current discussion).

On 06/05/2018 13:58, JORDI PALET MARTINEZ wrote:
> Hi all,
>
> I've the feeling that my message 
> https://lists.afrinic.net/pipermail/rpd/2018/008292.html
>
> was not read. People told me that the AfriNIC mailing list is not always forwarding my messages because the DMARC issue. Hopefully this is sorted out soon, as both ARIN and RIPE already did (I think APNIC as well, but not sure ...).
>
> So, repeating myself.
>
> I think it should be made clearer that:
> 1) The consensus is reached not only in the meeting, but also from the discussion in the mailing list, and because the mailing list has the capability to include a more broader community, it may happen that in the meeting the show-hands show no consensus, but the mailing list weight was "bigger" for the consensus, so the consensus is reached.
>
> 2) This means that the chairs MUST NOT take the decision right in the meeting, but have a 2 weeks period to really study the decision. This is the way we are doing in RIPE and also will be from now on in LACNIC.
>
>
> I've developed for LACNIC for a PDP change proposal which reached consensus the last week, a definition of both, consensus and last-call, which may be helpful here.
>
> Definition of ‘Consensus’
> Achieving ‘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 all’ (unanimity). More specifically, RFC7282, explains that “Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.”
>
> Last call
> The purpose of the ‘last call’ is to provide the community with a brief and final opportunity to comment on the proposal, especially to those who didn’t do so 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.
>
>
> This is the LACNIC proposal that reached consensus:
>
> https://politicas.lacnic.net/politicas/detail/id/LAC-2018-10?language=en
>
>
> Regards,
> Jordi
>  
>  
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>
>
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za      Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20180509/cacfd44f/attachment-0001.html>