Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Adam,

 

(thanks a lot, very good inputs!)

 

 

El 18/2/20 13:19, "Adam Gosling"  escribió:

 

Hi Jordi

 

Sorry, but I have a very close knowledge of these documents. They are not 
perfect (or even good). Everybody may not always understand them, or apply 
them. That is why I want to make sure people understand what it is they are 
changing from and what they are changing to.

 

-> I see your point, and fully agree. However, I think jugging a policy because 
the title says clarification may bring to wrong assumptions, depending on who 
reads that. I think it is clear that it depends on the perspective. And I can 
ensure that my point was not to convince anyone that this is minor change or 
anything like that, but saying that the guidelines are part of the PDP is also 
wrong, so the PDP doesn’t have a formal definition of “general agreement”.



On 17 Feb 2020, at 1:30 pm, JORDI PALET MARTINEZ  
wrote:

 

Hi Adam,

 

-> The first problem we have here is that those guidelines were developed long 
time ago (2 decades or so), when we had many SIGs, and they were developed by 
the SIG chairs, not the community. The 2nd issue is that the PDP doesn’t 
mention anything about the guidelines.

 

Then propose that we add a reference to the Guidelines into the PDP. We can 
easily reach consensus and move on.

 

-> I don’t think is that easy. Does the community agree that the guidelines are 
valid? It is a much more complicated task than a single reference.

 

This is not a mere editorial comment, it requires the community to accept those 
guidelines in a modification (thru a policy proposal) of the PDP. The third 
problem is that the PDP talks about “general agreement”, while the guidelines 
talks about “consensus”. It is a matter of English wording? I don’t know, but 
making it clear is good for everyone. Otherwise a newcomer will not see in the 
meeting that we are following our own process (because we aren’t!).

-> If I recall correctly, when asked at least one of the co-chairs about what 
they recognize as consensus, and I believe is the way they explain at the 
beginning of each Policy SIG, they use the rough consensus definition and I’m 
almost sure they even mention the IETF RFC.

 

The only reference Google finds to RFC7282 on the www.apnic.net or 
conference.apnic.net site is your presentation 

https://www.google.com.au/search?q=site:www.apnic.net+rfc7282=1=gTxLXuOENLuX4-EPpp-I8Ac

 

I checked the slides presented at the beginning of APNIC 46 and 47. These 
explain Consensus = ‘general agreement’ and the concept of Minor and Major 
Objections. They also provide the URL for the PDP and SIG Guidelines.

 

Anybody that says APNIC Policy runs on ‘rough consensus’ has made an assumption 
or is using the phrase to make it easier for you to understand to idea of 
'general agreement'.

 

 

 

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.

-> The RFC doesn’t provide the “operational” details, it is an informational 
document, so nothing precludes the co-chairs for their assessment to still make 
some “classification”, but again,  the guidelines aren’t part of the PDP, 
unless we change it. I think they key here, and again, I believe is the 
understanding of the chairs, if I got it correctly, we aren’t counting hands or 
votes, but instead we declare consensus “when all the issues are addressed, but 
not necessarily accommodated”, which is the “short” description of the RFC.

 

My reading of the Guidelines and the practice I have noticed from past Chairs 
is that Minor Objections can be 'addressed but not necessarily accommodated'. 
For Major Objections the guidelines say "When this happens, the Chair should 
encourage the proponent and the community to continue discussion and develop a 
more widely accepted proposal to be presented at the following meeting.” 

 

-> And this is rough consensus. So, there is consensus when there are minor 
objections. If there are major objections, then we need to continue the 
discussion and possibly have a new version: no consensus. I don’t see the 
difference with RFC7282.

 

I’m not saying that it is bad to change. I am just saying that we should be 
aware of what change we are making.

 


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.

 

 

-> Which I think is wrong. It is inappropriate (in my opinion) that (and it may 
be again an English understanding) chairs can “abandon” on behalf of the 
authors (I will understand “force withdrawal”). If there is an unpopular idea, 
the community will not reach 

Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[Adam Gosling]

Hi Jordi

Sorry, but I have a very close knowledge of these documents. They are not 
perfect (or even good). Everybody may not always understand them, or apply 
them. That is why I want to make sure people understand what it is they are 
changing from and what they are changing to.


> On 17 Feb 2020, at 1:30 pm, JORDI PALET MARTINEZ  
> wrote:
> 
> Hi Adam,
>  
> -> The first problem we have here is that those guidelines were developed 
> long time ago (2 decades or so), when we had many SIGs, and they were 
> developed by the SIG chairs, not the community. The 2nd issue is that the PDP 
> doesn’t mention anything about the guidelines.

Then propose that we add a reference to the Guidelines into the PDP. We can 
easily reach consensus and move on.

> This is not a mere editorial comment, it requires the community to accept 
> those guidelines in a modification (thru a policy proposal) of the PDP. The 
> third problem is that the PDP talks about “general agreement”, while the 
> guidelines talks about “consensus”. It is a matter of English wording? I 
> don’t know, but making it clear is good for everyone. Otherwise a newcomer 
> will not see in the meeting that we are following our own process (because we 
> aren’t!).
> -> If I recall correctly, when asked at least one of the co-chairs about what 
> they recognize as consensus, and I believe is the way they explain at the 
> beginning of each Policy SIG, they use the rough consensus definition and I’m 
> almost sure they even mention the IETF RFC.

The only reference Google finds to RFC7282 on the www.apnic.net or 
conference.apnic.net site is your presentation 
https://www.google.com.au/search?q=site:www.apnic.net+rfc7282=1=gTxLXuOENLuX4-EPpp-I8Ac

I checked the slides presented at the beginning of APNIC 46 and 47. These 
explain Consensus = ‘general agreement’ and the concept of Minor and Major 
Objections. They also provide the URL for the PDP and SIG Guidelines.

Anybody that says APNIC Policy runs on ‘rough consensus’ has made an assumption 
or is using the phrase to make it easier for you to understand to idea of 
'general agreement'.


>  
> 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.
> -> The RFC doesn’t provide the “operational” details, it is an informational 
> document, so nothing precludes the co-chairs for their assessment to still 
> make some “classification”, but again,  the guidelines aren’t part of the 
> PDP, unless we change it. I think they key here, and again, I believe is the 
> understanding of the chairs, if I got it correctly, we aren’t counting hands 
> or votes, but instead we declare consensus “when all the issues are 
> addressed, but not necessarily accommodated”, which is the “short” 
> description of the RFC.

My reading of the Guidelines and the practice I have noticed from past Chairs 
is that Minor Objections can be 'addressed but not necessarily accommodated'. 
For Major Objections the guidelines say "When this happens, the Chair should 
encourage the proponent and the community to continue discussion and develop a 
more widely accepted proposal to be presented at the following meeting.” 

I’m not saying that it is bad to change. I am just saying that we should be 
aware of what change we are making.

>> 
>> 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.
>  
>  
> -> Which I think is wrong. It is inappropriate (in my opinion) that (and it 
> may be again an English understanding) chairs can “abandon” on behalf of the 
> authors (I will understand “force withdrawal”). If there is an unpopular 
> idea, the community will not reach consensus. That’s it. Instead, chairs can 
> decide NOT allocate time in the agenda (if other newer proposals require more 
> time) for a proposal that is not getting consensus after several attempts, 
> but I think it has been demonstrated many times, that ideas that doesn’t work 
> on the first round, may work after 3-4 consecutive rounds (because the lack 
> of inputs in the list take much much much longer), and even sometimes, 
> authors may decide not to continue, and after some years come back and then 
> in works. This is normal, because all this is evolving all the time.

I see your point. I still disagree and would prefer the Chair’s to have some 
right to put a stop to unpopular ideas that are presented over and over. An 
earlier Chair started the three strikes rule, which seems to have become the 
norm. (He also used to reference the Tao of IETF in his slides)

This needs to be done carefully to stick to the 

Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Adam,

 

By the way, thanks a lot for all the inputs, just sorry that we only get them 
from one person and they are so late. If we can get discussions more time ahead 
the meetings, we can get much better text, for sure!

 

Below, in-line.

 

El 17/2/20 11:55, "Adam Gosling"  escribió:

 

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

 

-> Again, for me, in my native language, this is clarifying the situation. I 
don’t think it makes sense to discuss that, otherwise, we turn each proposal 
into a language discussion, which in turn, it will be differently understood by 
every non-native English speaker. The relevant thing here is what we actually 
do in the process and adapt the text to it, otherwise, we aren’t following our 
own PDP (our own rules).

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

-> The first problem we have here is that those guidelines were developed long 
time ago (2 decades or so), when we had many SIGs, and they were developed by 
the SIG chairs, not the community. The 2nd issue is that the PDP doesn’t 
mention anything about the guidelines. This is not a mere editorial comment, it 
requires the community to accept those guidelines in a modification (thru a 
policy proposal) of the PDP. The third problem is that the PDP talks about 
“general agreement”, while the guidelines talks about “consensus”. It is a 
matter of English wording? I don’t know, but making it clear is good for 
everyone. Otherwise a newcomer will not see in the meeting that we are 
following our own process (because we aren’t!).

-> If I recall correctly, when asked at least one of the co-chairs about what 
they recognize as consensus, and I believe is the way they explain at the 
beginning of each Policy SIG, they use the rough consensus definition and I’m 
almost sure they even mention the IETF RFC.

 

 

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.

-> The RFC doesn’t provide the “operational” details, it is an informational 
document, so nothing precludes the co-chairs for their assessment to still make 
some “classification”, but again,  the guidelines aren’t part of the PDP, 
unless we change it. I think they key here, and again, I believe is the 
understanding of the chairs, if I got it correctly, we aren’t counting hands or 
votes, but instead we declare consensus “when all the issues are addressed, but 
not necessarily accommodated”, which is the “short” description of the RFC.

 

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 is not late if we get some other inputs in the list … people 
supporting this one? I’m fine either way. For me the shorter version works 
fine, but again, there may be tiny English language details … What about (also 
reading your next paragraph and assuming that it is the Executive Council 
Chair, but this is easy to change in the final text if we send a new version 
and my recall or the actual situation is wrong):

“The Chair(s) assess if a proposal has reached consensus by considering 
discussions both on the mailing list, other electronics means and at the SIG 
Meeting. Consensus must be afterwards sustained at the Member Meeting for the 
process to continue, as observed by the Executive Council Chair.”

-> Note that my wording allows changing/evolving the (electronic) tools without 
requiring a PDP change (even incorporating several to facilitate the 
participation increase), and then there is no need to explicitly say that the 
tools are used for “measuring”, because that’s part of the consensus process. 
Also use SIG because this PDP seems to apply to policies developed by other 
SIGs, right? (if this is not currently the case).

I think retaining the 

Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[Adam Gosling]

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 

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"  nombre de su...@apnic.net> 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 

Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[Srinivas Chendi]

Hi Jordi,

Thanks for the new version. We've updated the proposal page. SIG Chairs 
will soon post version 2 of this proposal to the mailing list for 
community discussion.

Regards
Sunny

On 16/02/2020 12:38 pm, JORDI PALET MARTINEZ wrote:
> Hi Sunny, all,
> 
> I agree that we can improve this adding an explicit reference to the RFC7282, 
> and making clear that the policy expires if not updated by the next OPM, so 
> we don't depend on exact 6-months period, which not necessary will match from 
> meeting to meeting.
> 
> So, I think we should make a new version using the following text changes:
> 
> Previous version:
> 
> 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.
> 
> 
> New version:
> 
> Step 2: Consensus Determination
> Consensus is defined as “rough consensus” (RFC7282) 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 be considered as expired by the next OPM, unless 
> a new version
> is provided, restarting the discussions with the community.
> 
> 
> 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"  nombre de su...@apnic.net> 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
>  > jordi.pa...@theipv6company.com 
>  >
>  >
>  > 1. Problem statement
>  >
>  > The actual PDP doesn’t support the usage of electronic means to
>  > “measure” the consensus.
>  > 

Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I agree that we can improve this adding an explicit reference to the RFC7282, 
and making clear that the policy expires if not updated by the next OPM, so we 
don't depend on exact 6-months period, which not necessary will match from 
meeting to meeting.

So, I think we should make a new version using the following text changes:

Previous version:

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.


New version:

Step 2: Consensus Determination
Consensus is defined as “rough consensus” (RFC7282) 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 be considered as expired by the next OPM, unless a 
new version
is provided, restarting the discussions with the community.


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"  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
> jordi.pa...@theipv6company.com 
> 
> 
> 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 

[sig-policy] prop-134-v001: Secretariat impact assessment

[Srinivas Chendi]

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
> jordi.pa...@theipv6company.com 
> 
> 
> 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