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

[JORDI PALET MARTINEZ]

I will say try to apply common sense:

Is it possible to somehow assimilate that “specific” non-technical thing to a technical one?

Is this having an impact on Afrinic, Africa and the global Internet if we adopt or vs not adopting it?

It is just a few people (compared to the global community) opposing?

Do they have valid arguments to oppose?

Or it is more like a personal preference/view?

And the most important one: Have the authors tried to accommodate those opposing?

 

And then of course … this is the difficult part and must be done without any community micro-management, chairs need to decide by themselves, in the most objective way they can.

 

I’ve said this already many times … and that’s why I’m very thankful to chairs (past, present and future ones). I’ve done around 75 policy proposals up to now since I started contributing with RIRs (I think around 2003-2005). I think 99% reached consensus (I withdraw some, as in some cases on-purpose I did two, so to facilitate the people to decide). It looks a lot, right? Well I’m *more than happy* to make 100 or even 1000 more policy proposals than being a co-chair!

 

Again, thanks a lot for all your work!

 

Regards,

Jordi

@jordipalet

 

 

 

El 24/6/19 10:23, "Nasir Faruk" <nasirfaruk at gmail.com> escribió:

 

You are right. 

 

Mailing list could and should be able accommodate all form of discussion during the policy process. I dont really see what shoulnt be discussed here. In my opinion, all points during the meeting could also have been discussed here. Therefore, it is paramount for authors of policy proposals be oblige to contribute in the mailing list.

 

As Jodi rightly pointed on the RFC, rough consensus could be achieved when all issues (particularly objections) are addressed, but not necessarily ALL accommodated. 

 

My only concern will be objections without clear technical issues. This is what we should avoid.

 

Best Regards.

 

Faruk

..........................................................................................................
 
 
 
 
 

 

On Sun, Jun 23, 2019 at 2:28 PM <rpd-request at afrinic.net> wrote:

Send RPD mailing list submissions to
        rpd at afrinic.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.afrinic.net/mailman/listinfo/rpd
or, via email, send a message with subject or body 'help' to
        rpd-request at afrinic.net

You can reach the person managing the list at
        rpd-owner at afrinic.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of RPD digest..."


Today's Topics:

   1. Re: should authors of policy proposals be oblige to
      contribute in the list? (Mark Elkins)
   2. Re: should authors of policy proposals be oblige to
      contribute in the list? (JORDI PALET MARTINEZ)


----------------------------------------------------------------------

Message: 1
Date: Sun, 23 Jun 2019 15:04:17 +0200
From: Mark Elkins <mje at posix.co.za>
To: rpd <rpd at afrinic.net>
Subject: Re: [rpd] should authors of policy proposals be oblige to
        contribute in the list?
Message-ID: <c531b8dc-2a9f-e0e2-82c9-e8a5c0546248 at posix.co.za>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

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-0001.html>

------------------------------

Message: 2
Date: Sun, 23 Jun 2019 15:27:13 +0200
From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
To: rpd <rpd at afrinic.net>
Subject: Re: [rpd] should authors of policy proposals be oblige to
        contribute in the list?
Message-ID: <96269AFF-FEEA-46BC-9BBE-B5CC43409D5C at consulintel.es>
Content-Type: text/plain; charset="utf-8"

Hi Mark,



We do that (only list) in IETF and I think it is the only way forward!



The only RIR that now is doing this way is RIPE (for many years), and it works very well. It forces the people to actively contribute in the list, it makes the policy process to be straight forward and much faster. It requires a bit of extra work from chairs, but the staff can help them to summarize all the discussion points, different perspectives, etc.



Two years ago, I tried to make a PDP update in LACNIC following this approach, but during the discussion it was evident to me that it will not reach consensus so, I did a second policy proposal for making sure that the chairs officially consider the list AND the meeting (at that time it was only the meeting, like we have now in AFRINIC and APNIC).



My intent is to make this possible thru new policy proposals, maybe in about one year from now in LACNIC, and may be also around the same time for APNIC and AFRINIC.



I think we should have a much simpler PDP which facilitates, at least a bit, a small increase in community participation before going to the ?only list? approach.



Regards,

Jordi

@jordipalet



El 23/6/19 15:11, "Mark Elkins" <mje at posix.co.za> escribi?:



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
_______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd 



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

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

------------------------------

Subject: Digest Footer

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


------------------------------

End of RPD Digest, Vol 153, Issue 159
*************************************

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



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

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