Orbit

Hi Adam,

(thanks a lot, very good inputs!)

El 18/2/20 13:19, "Adam Gosling" email@adamgosling.com 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 jordi.palet@consulintel.es 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&gbv=1&...

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 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 policy. The Policy says; "The SIG will then discuss (either on the mailing list or in the SIG) whether to pursue the proposal or withdraw it.” So the SIG as a group can abandon work on a proposal. I interpret this to mean the Chair can propose that the SIG abandon work on a proposal (and not accept it idea back until circumstances change).

-> I could, in principle, agree that the WG takes that decision in the list, not in the meeting, because this will restrict the decision to those that are able to travel.

You are within your rights to question such a decision. The Chair(s) should be willing to hear counter arguments or there is no consensus for their decision. I would say if the Chair abandons your proposal, you should respectfully seek public support on the mailing list to demonstrate that there is no consensus for their decision. They might reconsider.

All this is very difficult if people do not participate.

-> Clearly this is the major problem we have. I’m not saying that APNIC community is “alone” on this. I’m participating in all the RIRs, IETF, etc. I see a trend, maybe something cyclic, of much lower participation since about 2 years ago. However, if I compare the size of the APNIC community (even understanding that there are many NIRs, languages, etc.), this is still close to zero. For example, as we use English as the language for the discussions, there are several official English-speaking countries in the region, and many other where the second language is also English (even if “not official”), which should be more “visible” in the discussions. I could also understand that there are cultural differences, but again, if you take the bigger official-English speaking countries, it seems to me that they also are closer to the culture of other regions that have more participation. Note that I’m not trying to “disturb” anyone, just trying to wakeup participation and trying to speak as openly as possible. The participation in the PDP is *part of the job* of anyone operating networks or responsible of the relation of its company with APNIC, and anyone coming to the meetings. You should be prepared for the discussion having read the proposal *before* coming to the meeting, asked for questions in the list (or directly to the authors if you’re shy), provided your inputs, etc. The decisions coming from the PDP affect you. You can’t ignore them. If you don’t contribute, you can’t complain later and you’re anyway bind to the rules developed there.

-> Again, let’s see if there are further inputs and then makes sense to send a new version tomorrow maximum? However, even if I like it, the timing is not correct, as the proposal deadline is for new proposals, not for new versions, so it needs some tuning. Maybe:

“Otherwise, the proposal will be considered expired unless a new version incorporating feedback is provided before the next OPM relevant deadline, to restart the discussions”

As I said, I like the idea. I don’t feel strongly about the wording. The proposal deadline is the time the Chair sets the agenda. A new version can be submitted much later and they would not know whether or not to include the proposal that had ‘expired'.

-> fully see your point here, this one may be better:

“Otherwise, the proposal will be considered expired unless a new version incorporating feedback is provided before the next meeting agenda is set by the Chairs, to restart the discussions”

-> I still thing the guidelines aren’t useful neither have been ever approved by the community, and instead either we make a Task Force to update the PDP and incorporate the guidelines, or to update the PDP to refer to the guidelines *and* the guidelines get also approved following the PDP.

Of course they are developed by the community. I wasn’t there for the formulation of the original SIG Guidelines, but I am pretty sure that any changes made to them in the last 12 years were made by the SIG community. These are not Chair or Secretariat guidelines. They are not a numbered document, but to the best of my knowledge, the practice has been that changes are owned by the community, reach consensus in all existing SIGs, and are run through the process outlined in the Document Editorial Policy.

-> Maybe I missunderstood it, but I asked this question and it was I have been told. Also tried to follow the history and didn’t found it.

Jordi I think the issues you are raising are really important because it demonstrates that people are not all that familiar with the documents and what they mean. There is definitely room for improvement in the documents and the processes, but getting agreement is often difficult.

-> Not saying is easy, I know how difficult is it! It takes time, it takes rounds of discussions, one more *clear* reason to not “abandon” a proposal !

Adam

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