[rpd] should authors of policy proposals be oblige to contribute in the list?

Sun Jun 23 12:09:11 UTC 2019

Hello Jordi, all

This thread you have started should help the community in reaching
consensus on most policy proposals within the shortest possible time.

Community members and proposal authors should be actively involved in the
discussions mailing lists.

I agree with “**There are no excuses** to be in the meeting and raise
something if you have already been in the mailing list and not raised it
before.”

Especially if the point raised is not new. Doing so will ensure that policy
proposals are optimised using inputs from the community and other authors
before policy meetings.

“If someone doesn’t support a policy proposal, **MUST say it in the list**
so it can be discussed and amended if necessary way ahead of the meeting,
so we can reach consensus, because the meeting time is precious, and
proposals are submitted to improve our system and this means if we believe
something is needed is much better reach consensus in 1 year than in 2.”

The quoted paragraph above by Jordi helps in driving my point home.
Authors/members should contribute to mailing lists discussions even if it
is not their proposal. Since we are all working for the good of the Afrinic
community. We don’t have to wait for meetings to make our perspective on
any proposal known to the community.

Thanks.

Haruna Umar Adoga

Department of Computer Science,

Federal University Lafia

Nigeria.

+234 8023836922

@harunaadoga

On Sun, Jun 23, 2019 at 12:32 PM JORDI PALET MARTINEZ via RPD <
rpd at afrinic.net> wrote:

> Hi all,
>
>
>
> I'm opening a new thread, and is not an easy one and could be very
> contentious, but I think is urgently needed.
>
>
>
> I mention it briefly in my previous email, but it was a long one, so I
> want to make sure that we concentrate in this part.
>
>
>
> Our PDP is meant for contributing in the mailing list for discussions and
> in the meeting. However, formally, the decision is taken in the meeting.
>
>
>
> Everybody that comes to the meetings is **able** to participate in the
> mailing list as well, so unless something "new" is discovered about a
> policy proposal, should we consider for the consensus that comments against
> a policy proposal that were not raised previously in the list, should not
> "take over" the gauge of the level of consensus support? **There are no
> excuses** to be in the meeting and raise something if you have already
> been in the mailing list and not raised it before.
>
>
>
> Sometimes, an issue raised in the list, may be too contentious to be
> resolved there, and that’s why we need meetings, and not just the “formal”
> policy day, but also chats in the breaks, etc. This the way we resolve
> issues in the IETF, where the definition of rough consensus was developed,
> and this is the one we use in the RIRs. RFC7282 and for short, read kind of
> summary of it below (1) my signature.
>
>
>
> Second part of this, and actually a **much stronger point**:
>
>
>
> Some folks, which are in the list, which are **actual** authors of other
> policy proposals, didn’t brought their inputs in the list, they have
> actually brought them in the meeting, just for the **insane sake of
> overthrow this proposal** and exclusively for their own interest.
>
>
>
> My view is that those authors, as I’m not supporting their own policy
> proposals, believe that I’m against them “personally”, it seems to me they
> don’t understand that the PDP is not about “your interest” but the
> “community interest”.
>
>
>
> If those authors of other policy proposals are really looking for the **well
> of the community**, they **MUST** participate in the list **not only** to
> defend their own policy proposals, but also to improve the ones from other
> authors (as I do).
>
>
>
> If they provid those inputs in the list in advance to the meeting, then we
> could have made a new version in time for resolving their issues and
> reaching consensus.
>
>
>
> If someone supports a policy proposal, **ideally, they should explicitly
> say it in the list**, so the co-chairs have a broader view of the real
> community support.
>
>
>
> If someone doesn’t support a policy proposal, **MUST say it in the list**
> so it can be discussed and amended if necessary way ahead of the meeting,
> so we can reach consensus, because the meeting time is precious, and
> proposals are submitted to improve our system and this means if we believe
> something is needed is much better reach consensus in 1 year than in 2.
> Obvious right?
>
>
>
> How come, as I learnt in the Dakar meeting (from one of the authors of a
> policy proposal under discussion who told me in person), can authors not
> read the mailing list and respond to, not only their own policy proposal
> inputs, but also contribute to others?
>
>
>
> Note that I explicitly don’t want to mention specific names, because,
> again, this is not about individuals, but about the community.
>
>
>
> So, should we have a rule, or at least co-chairs consider, that people
> contributing in the meeting, should have already contributed in the list,
> unless it is a new issue **not** discovered before?
>
>
>
> Again, this is not a fight among different sets of policy proposals
> authors, but it looks like when some of them, don’t do comments in the
> list, and wait till the meeting for killing consensus.
>
>
>
> Opinions?
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
> (1) 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.”
>
>
>
> Consequently, in this document ‘consensus’ should be interpreted as ‘rough
> consensus’.
>
>
>
> As an ‘abridged’ definition for the remainder of the document, a proposal
> is considered to have reached consensus when it is supported by meaningful
> opinions, after broad discussion, and when there are no irrefutable
> technical objections.
>
>
>
> Definition of 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.
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> 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
>

-- 
-- 
*Kind Regards,*

*Haruna Umar A*

*Computer Science Lecturer @ Federal University Lafia
<http://fulafia.edu.ng/>*
*GitHub/GitLab: harunaadoga <https://github.com/harunaadoga>*
*YouTube: Harun Umar
<https://www.youtube.com/channel/UCcs7cT_KebJheiFRq420g8g/>*

*Skype/Twitter: @harunaadogaEmail: haruna.umar.adoga at gmail.com
<haruna.umar.adoga at gmail.com>Office
Email: haruna.umar at science.fulafia.edu.ng
<haruna.umar at science.fulafia.edu.ng>*
*Mobile: +234 8023836922*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190623/8ec3418b/attachment-0001.html>