[Accountability-tf] Notes from Face-to-Face Meeting
Antony Gollan agollan at ripe.net
Mon Oct 2 15:24:42 CEST 2017
Dear task force members, Apologies for the delay, here are the notes from our face-to-face meeting in September. Please let me know if any corrections are needed. Cheers Antony ### RIPE Accountability Task Force Face-to-Face Meeting RIPE NCC Offices, Amsterdam 6-7 September 2017 Attendees: Athina Fragkouli, Antony Gollan, Malcolm Hutty, Alexander Isavnin, Peter Koch, Paul Rendek, Wim Rullens, Carsten Schiefner, Marco Schmidt, William Sylvester *I) Mind Map* *II) First Day* *III) Second Day* *I) Mind Map* The group started with a general discussion on values of the RIPE community, based on the mind map that had been prepared earlier by Malcolm, which is here: https://www.mindmeister.com/933814258?t=LHZApZN3rq Some of the topics discussed included: *Process Values* - Transparency. - Accessible by all. - Open and inclusive to all to participate. - Bottom-up. - Consensus-based decision making. *Substantive Values* - Everyone can use the Internet. - Interconnected networks/universal reachability/unfragmented IP connectivity - Stable and reliable Internet. - RIPE as a limited scope entity (while the scope may remain undefined, there are still limits). *Who is the RIPE community?* - Historical participants (academics, LIRs, IP address users, anyone on the mailing list, governments, network operators). - “All parties operating wide area IP networks in Europe” (RIPE-001) – maybe this could be updated to mention the rest of the RIPE NCC’s service region. - There is a distinction between who can participate and the community as a whole – ultimately RIPE is a technical IP operations community. - The RIPE community for the purposes of the task force is those that choose to participate in the plenary and/or the ripe-discuss mailing list. *How does the community hold the RIPE NCC accountable for its performance on behalf of the community?* - As an implementer of RIPE policy and as secretariat for RIPE. - Community policy governs RIPE NCC control of the RIPE Database. - RIPE NCC Services WG provides a consultation mechanism, the Activity Plan describes how the RIPE NCC will perform actions, and the Annual Report describes how it performed them. - Commonality between community participation and RIPE NCC membership provides an effective route for formal control, albeit the membership and community are not identical. - A question that can be researched is what commitments the RIPE NCC has to abide by community policy. *Who gets to decide things when there is no established process for taking a decision?* - RIPE community acting through the plenary and ripe-discuss mailing list (need to develop a narrative of why this is legitimate). - Expressing this as the “RIPE community” has pros and cons – while it sounds inclusive, it may promote confusion with broader senses of the community referred to in this definition. An alternative would be to call it the “RIPE plenary meeting and mailing list”. - Not the RIPE Chair as themselves, but they do articulate the RIPE community’s decision. *For whose benefit does the RIPE community work?* - RIPE-464 mentions that PDP policies are for the benefit of the “broader Internet community”. - A suggestion is that everything else that RIPE does is also for the benefit of the broader Internet community. However, there doesn’t seem to be any documentary evidence for this as an approved community statement – this would need to be confirmed by the community. - Another option would be to offer these two alternatives as options to the community and see their view on what they prefer. *Scope of RIPE* - To govern the policy for the management of IP address space in the RIPE NCC service region in order to facilitate interconnection between IP networks (RIPE-003, which is marked as obsolete). An alternative is to provide policy development process for the Regional Internet Registries (see RIPE-464). - To function as a Network Operators Group – to address abuse issues and have other discussions about wide-area IP networking. - Ancillary – to provide/request other services that assist, such as RIPE Labs activities, network intelligence, measurements, etc. Also to task the RIPE NCC to provide feedback on its services that satisfies the community. - NB: the community can task/mandate the RIPE NCC, but this authority is not absolute. Such tasking must be consistent with instructions from the RIPE NCC membership (e.g. within budget). ***ACTION ITEM: Malcolm to finalise the mind-map as a supporting document for the task force.* Some of the discussion of these points is included in the notes below. *II) First Day* The group started with a general discussion on values of the RIPE community. Much of this discussion centred on whether there could be a separation between “process values” (open, transparent, bottom-up) and higher level “substantive values” (good of the Internet, universal reachability, etc). Peter said the outside was looking in to see the legitimacy of their decisions as a community. Topics like the location of RIPE Meetings were an internal aspect of accountability. An external aspect was why the community had the authority to refuse a request from Law Enforcement to change RIPE Database fields. Alexander said they needed to use the language of governments when they produced their deliverables. While many governments in Europe would be able to grasp RIPE values easily (due to them being in many ways close to their own), other governments might have a harder time understanding this. It might help to present this to them in the kind of legalistic language they were familiar with. Carsten thought this was less of an issue now that there was greater participation from governments in forums like the Internet Governance Forum. Mirjam Kuehne [who briefly joined the meeting] replied to a point Alexander made about the increasing complexity of the RIPE community. She didn’t think the RIPE had gotten much more complex since the early days – WGs, TFs, Charters, etc – these were all there from the beginning. Topics changed, but the structure stayed fairly stable because it was flexible enough to grow with the community. She added that one of the goals of the community had always been to promote the use of IP and maybe this could be incorporated into the values. Paul said any values had to be something that could be held up on a flashcard. Values like transparent, and bottom-up had remained stable over time. They didn’t need to invent anything new for this. They didn’t need to be accountable to anyone else – they needed to be accountable to themselves as the RIPE community. Malcolm gave a hypothetical case where someone wanted to create a new structure in addition to the existing structures of BoFs, TFs, etc. Who was responsible for approving this? As a strawman, he suggested it was the RIPE Plenary. Peter said they had WGs and BoFs that went on forever, and TFs that appeared from nowhere, potentially with community opposition on the mailing lists. Despite this, there had never been a significant discussion in the plenary. If the plenary didn’t have the power to say no, its power to say yes didn’t mean very much. William said an alternative to Malcolm’s strawman was the community as the source of authority. Malcolm asked the community manifested. In contrast, it was easy to see how the Plenary or the RIPE Mailing List could express an opinion. Alexander said he remembered seeing a statement like “the RIPE Chair does what he does” in a mailing list discussion. Athina said they wouldn’t be able to say where authority came from, but they could say who could decide things. She suggested they look at this from the other end – by looking at decisions that could be made and who made them. Malcolm said he was interested in looking at the decisions that wouldn’t make that list. Malcolm said that when Rob had handed the RIPE Chair role to Hans Petter, he had tasked him with creating a replacement process. But he had also taken this to the Plenary and asked if there were any objections. He saw this as obtaining the community’s consent – when it came to this example where there was a clear lack of process, he had turned to the plenary and said: “This is my proposal, are you okay with this?” It mightn’t have been the greatest idea, but it was nonetheless a proposal. Wim said that doing it in this way provided space for someone to object and request a process be established. William said the RIPE Programme Committee (PC) could be an enabler or a gatekeeper. He’d seen non-politically correct presenters sometimes get the least desirable slot. He asked what happened if the PC was captured – people could affect the agenda of RIPE Meetings. Peter noted that the PC had given the Accountability Task Force a slot, and he had objected to this on the grounds that the PC was only responsible for the NOG parts of RIPE Meetings. Peter referred to the process around the code of conduct. It was a decision, because it was there, but there was something of a process failure. But the WG Chairs did have enough leeway, there so it wasn’t technically a process failure. Alexander created a flow-chart that outlined how the community reached agreement. Malcolm added that the first decision was to assign a venue where the discussion should take place (a WG, task force or in the plenary). Carsten added that the BoF was the most basic structure that you could put anything and everything into. William asked who they were referring to when they said “RIPE community.” Alexander said they should refer to the early days of RIPE to see how this had changed over time and how they had reached the current situation. ICANN had the GAC, but the RIPE community had nothing like this. At one point some Russians had tried to create a National Registry in Russia that had failed, and this had contributed to the situation. This had mostly started through academics and he thought someone should study this. Carsten referred to a phrasing in some places that said the RIPE community was open to “anyone with an interest in wide area IP networks.” Malcolm asked if it mattered that the Internet began with scientists or academics – at the end of the day they were network operators that happened to be scientists. Athina said they needed to make a distinction between the historical development of the participants and the current situation. Currently they were seen by the outside world as a technical community. The group referenced RIPE-001: “The area for RIPE is Europe” and “…all parties operating wide area IP networks in Europe.” Athina said this was more in the forming stages – the current situation was different. Wim said that government had several roles within RIPE – they could be network operators, but also had interests in terms of law enforcement, or in terms of the ecosystem of Internet governance, or how the technical community filled its role within this ecosystem and how they could support it. Malcolm said there were also academics and others in the community who had an interest in the dynamics of the community itself. He asked if this was the same type of participation as those who wanted IP addresses and services. Malcolm asked if each of those roles Wim mentioned gave him different roles within the community. Athina made a distinction between individuals and organisations – just because someone was from an ISP or ISPs participated, that didn’t mean RIPE represented business interests. Peter said governments didn’t participate within RIPE as governments – RIPE was not multistakeholder in that sense. True “multistakeholderism” in his understanding meant that the various stakeholder groups were represented as groups in an appropriate way. RIPE didn’t make this distinction. Only individuals had a voice within RIPE. This was in contrast to ICANN where they had the GAC and the various SOs and ACs. Malcolm said people often said “anyone from the street” could participate in RIPE. But they didn’t really get anyone from the street. If a vendor participated as a community member they were welcomed – though sales people were not as welcome if they don’t follow the mores. Marco said where you were coming from wasn’t relevant in the PDP. People were not invited to participate within the PDP as representatives of a government or a business, but as community members. It didn’t matter who you were or where you came from, if you participated appropriately, then you were welcome – provided you were willing to work within certain modes. If you were not willing to work in that mode, then you were not a member of the community. Peter said a sales person might be able to speak at the microphone, but to really be a member of the community you needed to have standing. If a sales person repeatedly showed up and broke the implicit rules, they wouldn’t be seen as part of the community – they would be visitors. In the old days, you knew you were in the community when you were invited to the Whisky BoF. Malcolm said he thought the community was fundamentally a technical community – so as a description, it wasn’t about having participation from academics, governments and other people. It was important to make it clear that this was what it was about. This was opposed to a multistakeholder environment, where these other entities (governments, salespeople, etc) could change the scope. This definition could prevent that – because the scope would belong to the technical community. Wim said there was a relationship between the scope of RIPE and the community. Participants in the community were interested in things that fell within the scope of RIPE. They didn’t need to have too many discussions about who was in or out of the community. Peter said they shouldn’t take it as a given that the RIPE community was the policy setting function of the RIPE NCC. Malcolm asked if there would be any need for the RIPE community if it was no longer setting policies for the RIPE NCC. Alexander said an existing consensus was why the DNS was able to run the way it was running. He said RIPE-003 made reference to the fact that RIPE was about interconnection. He added that sometimes government interference in IP networks was to break interconnectivity – so if they stated that they were working to maintain connectivity it might make it easier for them. There was some discussion about the relationship between RIPE and the RIPE NCC – and whether RIPE could get a new RIR, or whether the RIPE NCC could get a new community. There were differing views. Athina said the RIPE NCC had been created after the community decided it needed a registry and a secretariat. RIPE-003 reflected this back then. If the RIPE NCC didn’t want the RIPE community or vice versa, it was difficult to tell what would happen, so this was out of scope. Alexander said it would be great to remind the community that it existed to preserve connectivity. Ultimately, it wasn’t about IP addresses or a registry – these were small tasks to maintain global connectivity. Paul said the RIPE community could reach consensus that the RIPE NCC should spend money on a specific activity, but the GM could vote not to. There was a distinction between community members and RIPE NCC members (though in reality there was a lot of overlap). Athina suggested they ignore the RIPE NCC’s scope as it wasn’t really relevant to the work of the task force. Maybe the scope of RIPE was to give input to the RIPE NCC on how it could perform certain functions. Malcolm said their report could provide a bridge for obsoleted documents that were lacking a pointer to an updated version. They could link the document to their report. If they found some things and in their report said: “We suggest that an accurate scope of RIPE is as follows…” and if accepted by the community, it would allow the maintainer to insert a note saying “This document has been obsoleted by the statement in the Accountability Task Force’s report.” Paul said the accountability of the RIPE NCC was done – they had all their corporate documents in order. Alexander said this could be something about how the RIPE NCC saw its interactions with the community. Likely this had already been created – they could just rearrange what they had already published. Athina said they could just refer to already-published documents. The RIPE NCC’s scope was in the Articles of Association. In their contractual relationship with members, they specifically mentioned their relationship with RIPE policies. They could talk about the role of the RIPE NCC but this was also out of scope. Peter said they had also seen financial decisions interlocking with policy decisions, and this should be reflected somewhere. For example, there had been a case where the community had wanted a charge applied to Independent Resources, but the GM had voted against it. Malcolm said there was a financial accountability aspect. RIPE policy required people to use facilities managed by the RIR to make use of charged services. And the RIPE NCC spent its money on a broader set of activities than just registry services. This raised the question – to what extent did the community have accountability of the range of RIPE NCC services? The RIPE NCC was basically raising money from the community through the requirement that they use its registry services to access community resources. Paul said the community could make suggestions – but these still had to go through the GM/Executive Board. The board was able to release funds, but the RIPE NCC couldn't do this on its own. If the community reached consensus on a policy that was going to cost the RIPE NCC a significant amount, they would need to approve it with their board. Malcolm asked if non-members were provided with services that were charged for. Athina said there were non-member services that were provided for free, for example registry services, RIPEstat, RIPE Atlas, RIPE Labs articles. Independent Resources used to be charged-for non-member services. The only example at the moment related to one of the options in the legacy policy that essentially allowed legacy holders to pay the equivalent of a membership fee but not become members. Malcolm asked if there was a statement somewhere that said this was always how it would be. Charged-for non-member services raised the issue of accountability of fundraising and cross-subsidising activities. This would raise accountability issues with the broader Internet community, while the RIPE NCC still remained accountable to its community. Paul said they had the RIPE NCC Services WG for this. This meant that anything involving services was open to non-member community comment, which was then discussed at the members-only GM. Malcolm said this suggested that the WG had a right to be consulted/informed. Paul said the RIPE NCC didn’t have an obligation to inform them. They had set this up because they wanted to be transparent, not because they had to be. Athina said the RIPE community didn’t have to formalise these kinds of things, because if the RIPE NCC didn’t do what the community wanted, it would get shouted at by the community – so it had an interest in maintaining transparency. Malcolm agreed that there was a lot of trust there. But the cross-subsidy issue was a big question, and it wasn’t outside of the scope of the task force to look at these aspects. Paul clarified that when he said “we”, he meant not just the RIPE NCC, but the Executive Board and the membership. Issues fed in from the community, and were voted on at the GM. Paul said the board had no role in the PDP. The only thing the board could do was if a policy was created that would affect the health of the RIPE NCC financially or in other ways, the board could instruct the RIPE NCC not to implement it and take the issue to the membership. Peter said that running the RIPE Database was a core part of the RIPE NCC’s mission. It was not just the membership that should be getting reports about this but also the community. There was also the impact on policy development in the triangle between membership, community and the RIPE NCC – especially when the community had proposed a policy to put a charge on resources, there had to be some interaction with the GM, which refused it. Paul said when you looked at the database, it became interesting. When explaining it externally they said the community was responsible for it – but who was the community? When LEAs came to request changes to the database – or if someone had a question, where was the accountability on who would answer? Because at the moment it was the RIPE NCC that was taking this on. The RIPE Database might be more relevant in terms of accountability than the Address Policy WG. William mentioned the recent abuse-c policy proposal that would give the RIPE NCC a mandate to deregister networks without accurate abuse contact information. Malcolm said the community could still modify the proposal – perhaps it could remove the abuse-c field altogether or ask the RIPE NCC to police this a little less strictly. Paul mentioned in the past the community had proposed a 150 EUR charge for Independent Resources. This would have created tax and surplus problem for the RIPE NCC – and the board had intervened. He added that the only interactions between the RIPE NCC and the RIPE community were in the WGs, including the RIPE NCC Services WG. The group discussed that in the Articles of Association, it said that members would have to abide by community policy. However, there didn’t seem to be any statement or documentation anywhere that said the RIPE NCC had to abide by community policy. ***ACTION ITEM: the RIPE NCC to research and report back on what governance obligations are there for the RIPE NCC to abide by community policy.* The group discussed for whose benefit the RIPE community worked. William said this was ultimately about the community members themselves who benefitted. Malcolm said asking who benefitted was norm-setting. It wasn’t enforceable in any sense, it was more about culture. Malcolm asked if there was a clause somewhere that said RIPE NCC members couldn’t just choose to dissolve the RIPE NCC and distribute the profits. In Nominet’s bylaws there was a clause that prevented it from distributing its assets to members in the event that it was closed down. Instead, any proceeds had to go to benefit the Internet community in the UK. This was put in place to prevent the members of Nominet directing its activities in a way that would benefit themselves narrowly, as opposed to the wider community of .uk users. He was using this as an example to ask whether the RIPE community should have greater objectives than its own benefit. Paul said in the Articles of Association there were two options – to distribute any funds between members or to use this money for the benefit of the Internet community. Peter asked how these questions of who benefitted were answered in the ICANN CCWG-Accountability group’s work. Malcolm said in that case they had signed up to a series of value statements that were for the public good, but in very specific ways. The concern that this would be open to too much interpretation. This was probably much to heavyweight for the RIPE community. ***ACTION ITEM the task force to clarify with the community: Is public benefit a core aspirational factor, or are RIPE community members working for their own benefit? (There is also likely some research that can be done into RIPE Documents here as well).* William noted that RIPE-464, “Report of the RIPE Cooperation Task Force” seemed to have a lot of this stuff. It seemed to carry on some of the stuff from RIPE-001 and RIPE-003 – it gave you the where, the who and the how. It defined task forces, the RIPE community and its service region, etc. Malcolm noted that the document talked about the RIPE NCC membership being a subset of the RIPE community. This meant that RIPE NCC members were automatically RIPE community members. William said this document seemed to clarify a lot of this accountability ecosystem. Malcolm noted that the text in RIPE-464 also said policy proposals were accepted after it was agreed that they were for the benefit of the wider Internet community (so this seemed to settle that issue). The document had a lot of useful material on what the community had said about itself and should be referenced. The group said it should consider whether it needed to separate relevant parts from RIPE-464 and publish them together as a cohesive document. The group discussed the substantive values section on the mind-map. Athina said “Substantive Values” would create a ton of discussion in the community, so they’d need to reference documents if they wanted to make statements here. She could think of “We are not the routing police”, and “We do not care about content”. Alexander said connectivity should be expressed here as a value. Malcolm said surely everything they did was about making the network work. They shared the goal of making it work better. This was a tradition among the community – but difficult to find documentation supporting this. He said they should test this in a plenary. Athina suggested this was described in terms of “uniqueness” , “aggregation”, etc, that contributed to universal reachability and other desirable outcomes. They could base any new terms like universal reachability on these terms that RIPE could understand. Malcolm said he thought it was a community consensus that anything that didn’t contribute to universal reachability would not make it through the PDP. Peter said if they used the term “universal reachability” – a) community members would say “you’re not getting past my firewall and there’s nothing you can do about that” and b) governments would take this to mean that RIPE was the right place for them if they wanted to get involved and interfere with reachability. Alexander added that this couldn’t be translated into Russian and other languages. Malcolm said he hadn’t heard anyone object to the idea of their being a “universal reachability” value, only the way it was worded. Substantive values allowed them to have a benchmark for what they were reaching towards. Accountability wasn’t as narrow as bureaucratic regulations and process. You needed a standard to hold yourself to, and if they could articulate some of that, it would help in a broader sense. Having an agreed purpose gave a base for discussion. Even if it took a year for the community to reach agreement on these values, it wouldn’t be such a bad thing. Wim said this would be ambitious, but he agreed there was value in doing it. The community could still take wrong decisions through transparent, open, bottom-up processes. The only way you could know if you were wrong would be to have substantive values. Paul suggested “A stable and reliable internet.” Athina said they could pose this to the community as: “We believe there are implicit values, that aren’t (or are) documented, and we think they include these” – and allow the community to discuss this further. Peter said they shouldn’t reference “Security” or “A safe internet experience” – as this would open the floodgates and you would get the kinds of challenges around attempting to regulate content by abusing the identifier system. Malcolm said they could add “RIPE is a limited scope entity”, “RIPE is a technical body”, “RIPE is an operational body”. Peter added that there was a “public interest” clause that was used/abused to interfere with content regulation in ICANN. William summed up by saying that they could say to the community that these values were representative but not authoritative, and they thought having them defined could help RIPE when it checked itself. And they could highlight that this was just open to discussion. [End of first day] *III) Second Day* The group discussed what the output would look like. It was agreed that this would be a report, possibly with short separate documents prepared by the secretariat that explained various aspects of RIPE Accountability. Athina said the first step was to map out structures, which would reveal what was clearly documented and what was implied. For Dubai, they could present an outline of their work, instead of the flesh. William said they could do a 10-15 minute presentation at RIPE 75 with the rest of the time for comments. They could present certain areas where there were problems and ask if the community agreed they were problems. They could even farm certain parts out to the WGs to discuss. Malcolm said they should present accountability issues as documented vs undocumented rather than strong vs weak. He added that it might be worth having a section discussing documentation vs over-documentation, to demonstrate that they were aware that if they went too far with documentation, it would likely create a different set of problems. Peter said they should be looking at the PDP and the learned experiences of it being applied and other lessons from the way the community had been working. Almost all the instances of the PDP’s use had been in Address Policy WG, and the same Chairs had been in place all that time. The diversity of implementation was rather narrow to understand whether the PDP was robust and worked, or they just had people who were good at implementing it. Malcolm noted that consensus had not been defined in the RIPE community. The RIPE community’s understanding of consensus was similar to the IETF’s, but not identical. He asked if they should offer a strawman, or at least ask the community to develop its own definition. Peter said the recent Address Policy WG proposals were yes or no questions, so the decision making was questionable. It essentially boiled down to voting. Malcom said it was valid for scope to be invoked in policy discussions. If a person’s concerns could be classed as out of scope, the process could continue despite their objections. Marco referenced the recent proposal for a 24-month waiting period before IPv4 allocations could be transferred as an example of something that had divided the WG. Malcolm said in that case they had appealed to the greater good rather than the narrow self-interest of operators. Here, one of the responsibilities of the WG Chair in making the consensus call was making sure that objections were disposed of for valid reasons. Athina agreed that they could come up with a description of consensus, and the substantive values that went behind this. The Chairs who had been doing this had been there for years, and may feel comfortable and the community felt comfortable supporting them – with new Chairs, this might not be the case. William said that WG Chairs had a kind of “fiduciary duty” to the community. Chairs sometimes recused themselves in cases of conflict of interest, where they supported a policy themselves. The notion of Chair bias hadn’t been discussed anywhere and there didn’t seem to be a clear conflict of interest policy or documentation about this anywhere. He asked how many people there were in the community, and what if there was a flood of “+1s”. At the RIPE Meeting in Dublin, there had been a discussion on a proposal to remove needs assessment and there were all ARIN people speaking at the microphones. At one point the Chair had asked if there was anyone not from the ARIN region who wanted to speak. He also noted there had been no continuity with the recent selection of Chairs in the RIPE Database WG. Peter said the fact that this had gone through to being drawn from a hat had shown the process for what it was – an intention not to be bureaucratic that had produced a not-ideal outcome. William asked if they could put a strawman on consensus down or perhaps reference some other document. Malcolm said references to the IETF had limited applicability. RIPE made different decisions to the IETF – everyone had to follow RIPE policy, whereas they could choose to ignore IETF output. He volunteered to put together some wording around the definition of consensus and rough consensus. Consensus: everyone agrees; rough consensus: some disagree, but their objections are considered invalid. And then a definition of what constituted valid and invalid. ***Action item: Malcolm to work on drafting a definition of consensus/rough consensus to present to the community.* Peter said that weight was applied to arguments. The community considered whether someone was argumentative, of low standing, etc. While people often referenced the notion that one person’s objection was enough to prevent a consensus as an ideal, in practice it was different. He said they shouldn’t give themselves the authority to define consensus – they should find documentation to support their proposed interpretation that they would offer to the community. Malcolm said they should offer a statement to the community of what it meant, how it was used, and a statement for the community to endorse or discuss further. The idea was that ultimately the community would reach a definition that distinguished between consensus, rough consensus and unanimity. Peter said they should avoid the IETF tradition of different kinds of semi/full/partial consensus. In the RIPE community it was always just called “consensus”. He said that Rob had always reiterated that consensus did not mean unanimity at RIPE. Athina asked if something was less accountable if it was not documented. Malcolm said that if something was under documented, it did inhibit accountability. On the other hand, excessive documentation also undermined accountability – it reduced flexibility, encouraged opportunists or lawyers, and pushed things to the edges. It wasn’t necessarily that things weren’t there, but they were scattered, implicit, or spread across multiple documents, and it would be good to bring this together – not to create something new, but to codify what was already there. Peter said he’d never seen much appetite in the community for proactive documentation – he didn’t think many people would want to do this. Malcolm said it was about explaining to newcomers those things that everyone knew if they were there. The group discussed an outline of their final report: 1. Start with an explanation of what accountability is, why it’s important to the community, and what the risks of getting it wrong are. 2. Second part could focus on RIPE’s core values and standards, and what it is seeking to achieve. 3. Review of accountability mechanisms. What’s already there and how things are applied. Identify any gaps that suggest more work that could be done. The group turned back to substantive values. Interconnected networks could be a better term than universal reachability, though the group agreed that this was really about looking for a marketable heading and they could revisit this later. Regarding whether RIPE was a limited scope entity – RIPE does have a scope, but it’s not precisely defined. Maybe the best approach is to say: “The community does have a scope, but this is not clearly defined.” It was noted that PDP policies were for the benefit of the “Broader Internet community.” The group discussed that they would need some way of transferring some of the task force’s statements into normative statements for the future. E.g. the definition of consensus. The group would probably end up with a condensed reader-friendly report that was clear, and if people wanted to more detail, this report could be linked to a more substantive document that provided more detail. Referring to who benefits, Alexander suggested they make some higher-level statements along the lines of “for the benefit of humanity or the greater good” [this was given as an extreme example, he was advocating something a little more tempered]. Wim said it was difficult to make these kinds of statements and hold to them. Someone might take those words and use them to achieve something that was the opposite of what the community wanted. The group again discussed how the RIPE community could task the RIPE NCC to do things. If the RIPE NCC refused the community’s direction, the matter went to the GM and the Executive Board. So the community did have a kind of power, provided it didn’t interfere with the will of the membership. An example of this was the secondary DNS service provided by the RIPE NCC to certain ccTLD operators. The community had given some guidance – but then the RIPE NCC had taken the matter to the GM, which had supported the service, but with some restrictions on how much money the receiving entity had. This was despite the fact that the relevant documents were written by the community (the GM would never write documents). Another example was Certification (RPKI) – here the policy proposal had failed, but the membership had tasked the RIPE NCC to continue with the service anyway. Malcolm noted that in the case of RPKI, the programme had already been established and there was some reluctance to abandon it by the membership. He didn't think this was the best example of good governance, as the membership likely wouldn’t have tasked the RIPE NCC to build it if it didn’t already exist in some form. The group reviewed the accountability mapping document, which is available online here: https://www.ripe.net/ripe/mail/archives/accountability-tf/2017-April/000082.html It was noted that the columns to rank importance and quality were no longer needed and could be merged into one single “comments” section. Antony noted the difference between two types or classes of documentation – the RIPE NCC could publish something to the website without going through the community (e.g. the RIPE Meeting Locations page), while it was unable to make even minor editorial changes to a RIPE document without it being republished with a new document number. The group reviewed some of the roles outlined in the document: 2.3 Announce final best practice documents (or other output) created by WGs This could be updated – a WG could conceivably approve a BCP without it getting a RIPE document number. Peter noted that documents could often be marked as obsolete without an explanation of why or a link to a more up-to-date version. Some were just old historical documents, others needed an “obsoleted by”. Alexander suggested they add a role for WG Chairs in approving the WG minutes from RIPE Meetings. 3.1 Select WG Chairs The group agreed that this needed to be discussed further by the task force. 4.2 Discuss RIPE Meeting Plan (RIPE Chair makes final decision) This was about which WG gets which slot during the meeting – the group agreed to leave this for now as it was of low importance. 5.1 Produce a report with recommendations that will be discussed by the RIPE community and implemented when consensus is reached Add a reference to RIPE-464. However, as a reference, this is problematic – it’s more of an observation than a definition. Needs review, the task force can make recommendations here. 6.2 Chair plenary sessions Doesn’t need to be documented, as this comes under the umbrella of the RIPE Chair’s role as RIPE Meeting Chair. Need to create a section that talks about BoFs. 7.0 Plenary Plenary role needs discussion 7.1 Approve new WGs Needs to be documented. 10.0 History/Mandate Add RIPE-003 to history/mandate and look for other documents to add to this section. 11.0 Participation requirements Some of this could be documented. Sections 10,11,12,13 need further review. The group discussed what the next steps should be: 1. Send an update email to ripe-list a week or two before RIPE 75 with a brief update of where the task force is at, and informing the community that they will be presenting at the meeting. 2. A presentation at RIPE 75 that gave a 10-15 minute update on the progress of the task force and outlined when they expected to publish something. This should also include a timeline. A summary of what was discussed at the face-to-face meeting would also be good to include. *Action Items* *20170907-1: Malcolm to finalise the mind-map as a supporting document for the task force.* *20170907-2: RIPE NCC to research and report back on what governance obligations are there for the RIPE NCC to abide by community policy.* *20170907-3: the task force to clarify with the community: Is public benefit a core aspirational factor, or are RIPE community members working for their own benefit? (There is also likely some research that can be done into RIPE Documents here as well).* *20170907-4: Malcolm to work draft a definition of consensus/rough consensus that can be presented to the community.* *20170703-2: RIPE NCC to look for past statements/presentations that might be relevant to the TF’s work.* *20170509-1: TF Chairs to put together work plan after the meeting.* *20170306-1: RIPE NCC to further develop accountability mapping document with task force input.* *20170306-2: Task force members to review and comment on accountability mapping document.* -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2609 bytes Desc: not available URL: <https://lists.ripe.net/ripe/mail/archives/accountability-tf/attachments/20171002/c9b011dd/attachment-0001.p7s>