Hi Jordi 

My comments are inline

> 
> New version:
> 
> Step 2: Consensus Determination
> Consensus is defined as “rough consensus” (RFC7282) as observed by the Chairs.
> 

You are making a significant change, but presenting it as a “clarification”. 
It is okay to consider adoption of IETF definitions of “rough consensus” to use 
in the APNIC Policy Process, but this is not a clarification. To be clear, the 
SIG doesn’t currently use the “rough consensus” model in RFC 7282. It uses the 
consensus model in the APNIC SIG Guidelines. 
https://www.apnic.net/community/participate/sigs/sig-guidelines/#steps 
<https://www.apnic.net/community/participate/sigs/sig-guidelines/#steps>
The RFC is similar, but fundamentally different. Changing this in the PDP is 
not just a word tweak. It would result in a different approach from the Chairs 
and participants. There is no concept of “Minor” and “Major” objections in RFC 
7282, for example.



> Consensus is determined first considering the SIG mailing list, other 
> electronic means, and the SIG session, and afterwards at the Member Meeting.

I’m supportive of the spirit of this change.

It’s a bit late in the day to be proposing changes, but I would have written: 

“The Chair(s) assess if the SIG has reached consensus on a proposal by 
considering discussions both on the mailing list and at the Open Policy (Policy 
SIG) Meeting. The Chair(s) may use measurement techniques to take the 
temperature of the room. Consensus must be reached first at the SIG session and 
afterwards at the Member Meeting for the process to continue."

I think retaining the “process to continue” wording is important. I also think 
there is a lack of clarity about who is deciding Consensus at the Member 
Meeting. Is it the APNIC Executive Council Chair? The Chair of that particular 
meeting? The Policy SIG Chair? Or the Co-Chair presenting the report?

> 
> If there is no consensus on a proposal, the authors can decide to
> withdraw it.
> 

This removes discretion from the Chair (and the SIG), to abandon a proposal if 
an Author repeatedly persists with the same unpopular idea. I think that’s 
interesting and worth discussing if that’s what we want.



> Otherwise, the proposal will be considered as expired by the next OPM, unless 
> a new version
> is provided, restarting the discussions with the community.
> 


I like the idea that a proposal has to change before it can be re-presented. In 
the past, authors have just re-presented the same proposal until they get an 
friendly crowd and it passes. The effects of this have been negative IMO. 
Also, could I just add white space to the proposal and say that it has changed? 
How about this wording?

"Otherwise, the proposal will be considered expired unless a new version 
incorporating SIG feedback is provided before the next “Proposal Deadline” to 
restart the discussions.”

I hope these suggestions help. It is very difficult to make changes to the PDP. 
This would also require changes to the SIG Guidelines.

Regards,

Adam



> 
> Please, update the version number of this proposal with these changes, which 
> I guess clears your impact assessment as well.
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 14/2/20 14:47, "Srinivas Chendi" <[email protected] en 
> nombre de [email protected]> escribió:
> 
>    Dear SIG members,
> 
>    Here is the Secretariat impact assessment for proposal “prop-134-v001: 
>    PDP Update” and the same is also published at:
> 
>         https://www.apnic.net/community/policy/proposals/prop-134/
> 
>    Staff comments
>    --------------
> 
>    No foreseen change on APNIC Services procedures or systems as a result 
>    of this policy proposal.
> 
>    For reference and definition of “Rough Consensus” suggest adding RFC 
>    7282 to the proposed text.
> 
>    It is difficult to keep track of proposals “expire in six months” may be 
>    change to “expire at the next OPM”.
> 
> 
>    Technical comments
>    ------------------
> 
>    No comments.
> 
> 
>    Legal comments
>    --------------
> 
>    Given that rough consensus is defined under RFC 7282 - no further comments.
> 
> 
>    Implementation
>    --------------
> 
>    within 3 months.
> 
> 
>    Regards
>    Sunny
> 
> 
>    On 20/01/2020 10:23 am, Bertrand Cherrier wrote:
>> Dear SIG members
>> 
>> The proposal "prop-134-v001: PDP Update" has been sent to the Policy SIG 
>> for review.
>> 
>> (This is a new version of "prop-126" proposal abandoned after APNIC 48 
>> as it did not reach consensus at APNIC 46, APNIC 47, and APNIC 48.)
>> 
>> It will be presented during the Open Policy Meeting at APNIC 49 in 
>> Melbourne, Australia on Thursday, 20 February 2020.
>> 
>> We invite you to review and comment on the proposal on the mailing list 
>> before the meeting.
>> 
>> The comment period on the mailing list before an APNIC meeting is an 
>> important part of the policy development process. We encourage you to 
>> express your views on the proposal:
>> 
>>  * Do you support or oppose this proposal?
>>  * Does this proposal solve a problem you are experiencing? If so, tell
>>    the community about your situation.
>>  * Do you see any disadvantages in this proposal?
>>  * Is there anything in the proposal that is not clear?
>>  * What changes could be made to this proposal to make it more effective?
>> 
>> Information about this proposal is available at:
>> http://www.apnic.net/policy/proposals/prop-134
>> 
>> Regards
>> 
>> Sumon, Bertrand, Ching-Heng
>> APNIC Policy SIG Chairs
>> 
>> ------------------------------------------------------------------------
>> 
>> prop-134-v001: PDP Update
>> 
>> ------------------------------------------------------------------------
>> 
>> Proposer: Jordi Palet Martínez
>> [email protected] <mailto:[email protected]>
>> 
>> 
>>    1. Problem statement
>> 
>> The actual PDP doesn’t support the usage of electronic means to 
>> “measure” the consensus.
>> However, “Confer” is being used. This should be clarified, or otherwise 
>> the process is not fair (remote participants don’t know about it reading 
>> the PDP) and can be considered a violation of the PDP itself.
>> 
>> The PDP also don’t have a formal process to withdraw a proposal, and 
>> doesn’t force the authors to keep editing it according the community 
>> inputs, or otherwise, allow the SIG chairs to declared it as expired.
>> 
>> Finally, as editorial change, the expression “rough consensus” (RFC7282) 
>> is used instead of “general agreement”, so it is consistent with the 
>> actual practice.
>> 
>> 
>>    2. Objective of policy change
>> 
>> To resolve the issues above indicated.
>> 
>> 
>>    3. Situation in other regions
>> 
>> The PDP is different in the different RIRs.
>> 
>> 
>>    4. Proposed policy solution
>> 
>> Actual Text
>> Step 2: Consensus at the OPM
>> Consensus is defined as “general agreement” as observed by the Chair of 
>> the meeting. Consensus must be reached first at the SIG session and 
>> afterwards at the Member Meeting for the process to continue.
>> If there is no consensus on a proposal at either of these forums, the 
>> SIG (either on the mailing list or at a future OPM) will discuss whether 
>> to amend the proposal or to withdraw it.
>> 
>> Proposed Text
>> Step 2: Consensus Determination
>> Consensus is defined as “rough consensus” as observed by the Chairs.
>> 
>> Consensus is determined first considering the SIG mailing list, other 
>> electronic means, and the SIG session, and afterwards at the Member Meeting.
>> 
>> If there is no consensus on a proposal, the authors can decide to 
>> withdraw it.
>> 
>> Otherwise, the proposal will expire in six months, unless a new version 
>> is provided, restarting the discussions with the community.
>> 
>> 
>>    5. Advantages / Disadvantages
>> 
>> Advantages:
>> Fulfilling the objectives above indicated and making sure that there is 
>> no formal discrimination with community members that aren’t able to 
>> travel so they know that they can participate via the Confer or other 
>> systems developed by the secretariat.
>> 
>> Disadvantages:
>> None foreseen.
>> 
>> 
>>    6. Impact on resource holders
>> 
>> None.
>> 
>> 
>>    7. References
>> 
>> http://www.lacnic.net/679/2/lacnic/policy-development-process
>> https://www.ripe.net/publications/docs/ripe-710
>> 
>> Cordialement,
>> 
>> ------------------------------------------------------------------------
>> 
>> Bertrand Cherrier
>> Micro Logic Systems
>> https://www.mls.nc
>> Tél : +687 24 99 24
>> VoIP : 65 24 99 24
>> SAV : +687 36 67 76 (58F/min)
>> 
>> 
>> *              sig-policy:  APNIC SIG on resource management policy          
>>  *
>> _______________________________________________
>> sig-policy mailing list
>> [email protected]
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>> 
>    *              sig-policy:  APNIC SIG on resource management policy        
>    *
>    _______________________________________________
>    sig-policy mailing list
>    [email protected]
>    https://mailman.apnic.net/mailman/listinfo/sig-policy
> 
> 
> 
> **********************************************
> 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.
> 
> 
> 
> *              sig-policy:  APNIC SIG on resource management policy           
> *
> _______________________________________________
> sig-policy mailing list
> [email protected]
> https://mailman.apnic.net/mailman/listinfo/sig-policy

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
[email protected]
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to