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

Sun Jun 23 13:04:17 UTC 2019

Again you are correct. The PDP meeting should really only be used for 
formal presentations and to perhaps clarify anything - although even 
that could be done in the mailing list. The meeting can also perhaps be 
used to provide a summary of discussions on the mailing list. The 
decision really should not have to happen in the meeting - it should 
almost be a foregone conclusion whether a particular policy is going to 
go to "final call" or not.

I wonder if we as a community will ever have the possibility of a policy 
going from inception to passing without it ever having to wait for (or 
going to) a meeting. That should be possible.

On 2019/06/23 13:30, JORDI PALET MARTINEZ via RPD 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

-- 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190623/9ad277ef/attachment.html>