Hi everyone,

We had a good discussion on yesterday's call - here are the minutes. 

Cheers

Antony

***

Accountability TF call minutes - 14th call (working call)

Attendees: 
Antony Gollan, Malcolm Hutty, Alexander Isavnin, William Sylvester

Agenda:
1. Consensus (sections 2.1.1 and 2.1.1.1 in draft document)
i) The role of the chair in determining consensus - determining whether an objection is valid or not.
ii) When does "Silence is consensus" apply? Is there a minimum of participation required for consensus to be legitimate?
iii) What are the differences between RIPE and the IETF's understanding of consensus?

1. Consensus (sections 2.1.1 and 2.1.1.1 in draft document)

i) The role of the chair in determining consensus - determining whether an objection is valid or not.

William said there were different kinds of objections. There were people who objected on valid grounds, and there were sometimes trolls who wanted to cause trouble. A chair might also object that people were being self-serving in their objection. There was a recent example from Anti-abuse WG where a bunch of people began participating with a narrow self-interest in mind and were told to sit down.

William said that when the community made consensus decisions, it was with the greater good in mind. Decisions were favoured that lead to the best result for the greatest number of people. In his experience as chair of the Database WG, you could propose something and if no one objected, you could go forward. This was provided you weren't railroading policies through final calls and were giving people ample time to respond.

Malcolm said if you have 99% of the community in agreement about one point, it could still be held up if an objection was valid. However, in this case the mere fact of numbers might say something about the nature of the objection (provided the community hadn't been flooded with outsiders in an attempt to game the process). It all came down to whether the objection was valid or not.

Malcolm said William had made the distinction of self-serving objections. This was where an objection could be ruled as out of order. However, self-serving wasn't the same as conflict of interest - everyone in the community had their own interests. It was hard to express, but when RIPE came together, it was because the community had a shared interest in a common enterprise that they were trying to make work. If the other person shared that intention and had a different opinion, then there was a discussion to have about whether something was a good idea or not. But if someone was not a part of that enterprise and was trying to sabotage it, they could be ignored. And if they were only trying to make things the way they wanted them, then it was also legitimate to rule out their objection. But the chair would have to be careful in this case - because if the proposal didn't work for one person, it might not work for others.

William said it went both ways. Sometimes the community might want to sabotage something - e.g. a recent law enforcement proposal. It seemed like everyone went to the meeting to shoot it down because they felt it wasn't in the best interests of the community, as it was self-serving.

Malcolm agreed. RIPE had a common enterprise that they were engaged in collectively. The LEA wasn't engaged in the common enterprise, they were simply bringing in their own interests.

William referenced inter-RIR transfer policy discussions in the Address Policy WG where ARIN community members were trying to advance their own agenda at RIPE Meetings. At one point the chair had said: "Is there anyone not from ARIN who wants to speak?" Ultimately their opinions were shut down as not legitimate.

Malcolm said the consensus call was whether there was consensus in the community. But what was the community and how did you describe it? If someone was not willing to support the collective enterprise and were only serving themselves, then at that specific time and for that purpose they were not a part of the community.

Malcolm said it wasn't that ARIN's view wasn't part of the consensus, it was that the community decided its consensus for one preference ranked above the problems that would be caused by RIPE's approach being different from the ARIN community's. But at no point of that process was ARIN was acting as part of the community - as they were only seeking to ensure that their [ARIN's] policy was followed. And it wasn't part of the RIPE community's enterprise to ensure that ARIN sets the policy for this region.

Malcolm said if you demonstrated good faith in the way you participated in the process, you were included.

ii) When does "Silence is consensus" apply? Is there a minimum of participation required for consensus to be legitimate?

William said some people would say that vocal support was needed for consensus, while others would take the opposing view.

Malcolm said they were talking about the consensus of the community. If no one disagreed, in many instances that could be the will of the community. There was a kind of "rational ignorance" that people might be applying when they chose not to participate in a particular discussion. This was a perfectly reasonable response. They might conclude that they don't know as much about the topic as others in the discussion and may not want to invest the energy to learn about it. Low participation could also be because it's not that important and people could trust that the right people were making the decision and they would get it right. On the other hand, if some big deal was being snuck under the radar without the community noticing, then in that case silence was not consensus.

William said that seemed like a kind of macroeconomic argument that also applied to people choosing not to participate in the community at all. If someone had IP addresses and was a RIPE NCC member but chose not to participate - were they really a member of the community? Also, people might choose not to participate in a certain part of the community while participating in others. He was involved in the RIPE Database WG, for example, but not in the new IoT Working Group. Also, if he was on a mailing list, then maybe his silence was really an abstention.

Malcolm said the only time this would really be an issue was if a group of people were doing something that would have a big impact on others who didn't know about it.

William asked about people who might forum-shop between WGs because they thought the culture or personalities in a specific WG would be more likely to support their proposal. On the other hand, there seemed to be a self-correcting mechanism where chairs would try and see if it was the appropriate WG, or invite other WGs to participate. An example was a recent proposal in the Database WG that would also have an impact on routing.

Malcolm said forum shopping was abusive by principle. If you were aiming to avoid a bad reaction from a group of people, you were acting in bad faith.

William said the question was whether it was nefarious or whether it was something that happened of its own accord. If you had to choose a venue, you would obviously aim for the one where you were more likely to have success.

Malcolm said that was fine, but concealment was not okay. The reason that would be abusive was that even though it was the WG that declared consensus, they were saying that it was the consensus of the wider community. And they were assuming that everyone with an interest would be there. But concealment was a rebuttal of this claim - if you had reason to believe that people with an interest were not there, then the presumption that you were speaking for the community wasn't valid.

William asked where you drew the line. What was the test of bad faith? 

Malcolm said a determination in a specific case would always be subjective and potentially controversial. One of the responsibilities of the chair was to consider these kinds of questions. If they might not reach consensus with certain people involved in the discussion - could they really say that they had consensus with those people absent? If the WG chair believes that the people assembled before them don't show a real representation of the community, then they shouldn't be declaring consensus.

William said before he became the Database WG Chair, he had made a couple of proposals that didn't get much traction with the community because they were narrow changes that addressed corner cases. At one point he thought they were ready to go forward, but the chairs mentioned they had discussions with community members who didn't support it. So they were reluctant to move the proposal forward in the PDP, despite there being no opposing posts on the mailing list.

Malcolm said that if the chair was acting in bad faith, they could exaggerate these claims and use them to hold up the process. However, if it the chair was acting in good faith, and did legitimately believe that there was a lot of opposition in the community, then there wasn't consensus.

William said a lot of WGs claimed that the work took place on the mailing list. Others conducted their business at RIPE Meetings, with certain pieces carried out on the mailing list. In the Database WG, they had one participant who had valid objections but didn't want to participate on the mailing list. So it was creating an interesting challenge trying to get them to participate in some form.

iii) What are the differences between RIPE and the IETF's understanding of consensus?

Alexander said the IETF didn't only believe in rough consensus - it also believed in running code. That made a difference. If you wanted to support an idea, you could bring some running code. In the case of RIPE, it was much more difficult to talk about the effectiveness of policies that dealt with primarily administrative matters (such as the multiple-LIR issue). Because of this, RIPE had to be more accurate and thorough with its consensus, as there was generally less available proof to support an argument.

Malcolm said that was a very good point. Rough consensus was not the sole criterion for proof at the IETF - you needed rough consensus and running code. Without code, you were not going forward. Because RIPE didn't have running code in this sense, they put more weight on consensus. So they needed to be more careful about the consensus call.

Malcolm said another point was the difference in what the two communities discussed. IETF developed protocol standards. RIPE was basically developing operational policies. At the IETF, you might see a bunch of people come forward and say: "We want to work on this and will develop the code" and someone else would say "I don't want you to do that." But that wasn't such an obstacle as it might be in RIPE.

Malcolm said another difference was that there was still the question of adoption, even after you had an RFC. People didn't have to adopt IETF standards and many weren't adopted. That's why the IETF could afford to be a little weaker in how it understood and applied consensus - because no one was forced to use the standards. In certain areas, where you were somewhat forced to use a standard, they were much more rigorous in their determination of consensus. In the RIPE world they were making policy that would apply to everyone. If the community decided that you needed to update a certain part of your RIPE Database information, then people would either have to do that or they would lose their allocations.

William said they were talking about how the RIPE community was making policy that was universal and absolute.

Malcolm said he believed there were a very large number of IETF standards that had no real take-up and had made no significant impact. It wasn't universal and it wasn't absolute. He suspected there was a difference in the way consensus was applied across the IETF - the test of whether or not there was general support for something was quite lenient if it was a side project, but if you wanted to modify a core protocol, it would be a much higher bar to cross.

Alexander suggested that they could make footnotes in their text with examples that supported their points and showed why they had raised them. Alexander also requested they put together a review of the current situation with RIPE Documents, so they could discuss it a little more productively.