RIPE 76 Address Policy Working Group Minutes

Chairs: Gert Doering, Sander Steffann, Erik Bais
Scribe: Antony Gollan

A. Administrative Matters

Gert welcomed attendees and said they would be selecting a new WG Chair at this session, with Sander stepping down as co-chair.

The minutes were adopted without comment.

B. WG Chair Selection

Gert said the process was that one chair stepped down every year, and this gave others an opportunity to volunteer. This time Sander was stepped down and was not seeking another term as chair. When they had published this on the list, Erik Bais had volunteered with a lot of support, and Sean Stuart had decided not to compete with Erik.

There was a hum and Erik was appointed as the new WG Chair.

The WG applauded Sander, who had been an Address Policy WG Chair for 11 years.

C. The Role and Function of the ASO within ICANN (Public Consultation)

Axel Pawlik, RIPE NCC

This presentation is available here:
https://ripe76.ripe.net/presentations/70-RIPE-76-ASO-Review-v0.7key.pdf

Dmitry Burkov, RIPE NCC Executive Board, asked if Axel had more information on how expanded the ASO involvement within ICANN had become. He understood there were dozens of WGs completely unrelated to the activities of the Number Community. He said they should simplify their relationship with ICANN and not create a new bureaucracy. They should keep their distance from activities which had only political goals.

Axel said that whenever they heard about ICANN, they rarely saw IP addresses mentioned. They attended meetings and reached out to the community. When they ran sessions on IP addresses at ICANN meetings, the rooms were mostly empty. ICANN really wasn’t about numbers that much, it ran IANA/PTI, and was part of the Global Policy Development Process (GPDP), but there wasn’t much in it for them. It was important that ICANN ran smoothly, and that the Number Community had influence when needed, but they should be careful with what they engaged with. 

Dmitry said the Empowered Community was really about firing ICANN board members.

Axel said it was a structure that let the community influence ICANN’s budget, or fire individual board members, or the entire board. This was a good thing, as the ICANN that came out of it was a better one. But their role within ICANN was a limited one, and the effort and money they spent on it should be similarly limited. Aside from the IANA/PTI, there were global policies, where text that had been agreed upon by the RIRs was sent to the ICANN Board for ratification. But this only happened once every few of years or so.

Dmitry said they should discuss the role, size and structure of the NRO Number Council (NC). He asked whether they should have a huge NC that was looking for something to do. There were some people in the APNIC region who were trying to raise the role of the NC. He asked if they needed all this bureaucracy.

Sebastian Bachollet, Afnic Board, said he would speak from an End User perspective, as an ex-ICANN Board member, and a member of the At-Large Community. He didn’t like it when ICANN talked about the domain name system and forgot about IP addresses. They needed to add in their reflection that ICANN would survive and still be useful if it was really a multi-stakeholder organisation. He urged the Number Community to stay, because it was needed there. He suggested they request a slot at ICANN meetings where people could come, and they also needed something at the beginning of an ICANN meeting where the Number Community could say what it had been doing since the last meeting – because if people did not hear from them, they would not know them.

Axel clarified that he wasn’t complaining about ICANN not being willing to give them slots at their meetings. It was the ICANN community – the people who came to the meetings – who had a completely different focus. But he agreed they should speak with these people.

Peter Koch, DENIC, said he could understand the desire to decrease participation. However, while there was no desperate need for the Number Community to be involved or to have the ICANN Board involved in the next global policy development, they only had one Internet. It was good to have working examples in the middle of this multi-stakeholder zoo. It was important that the Number Community filled its seat within ICANN so that no one else did.

Axel said this was the second comment that had referenced leaving ICANN – the report made no mention of this and they weren’t recommending it. He personally thought they should remain involved.

Nurani Nimpuno, Asteroid International / NRO NC, clarified that they were talking about two things. The first part was the Empowered Community, which was a process that came out of the accountability work that had been done in ICANN. The ASO was in a funny spot, as its hadn’t initiated this process but was affected by it, as the ASO was part of the ICANN structure. The second part was the ASO Review, where they wanted to hear the community’s thoughts on the ASO and the how it structured its work. She often heard feedback from people that they didn’t know what the ASO was. This seemed to be something that could be clarified. 

Filiz Yilmaz, NRO NC, said the ASO AC wasn’t there to take part in the bureaucratic parts – the NRO EC was there for that. What was happening with this review was that the ASO AC and NRO NC were being put into their proper roles. The ASO AC was responsible for helping with the Global Policy Development Process and selecting two ICANN Board members.

Axel agreed with Filiz but added that procedures in the Empowered Community involved the “ASO”. Over the last couple of months, they had been trying to figure out who this ASO was – whether it was the NRO EC or the ASO AC, depending on what the intervention related to.

Hans Petter Holen, RIPE Chair, said he had spent many years on the ASO AC as chair, co-chair, and member, and on the NomCom. He had been through all the phases of being welcomed at ICANN, being urged to do more at ICANN, and being urged to do less. The Number Community had come quite far within ICANN through participating at meetings (not necessarily from being on the stage). With more than 800 people at this RIPE Meeting, they were a huge community, even compared to ICANN, and they needed to keep this in mind. The report they were discussing was written by an independent group that had talked to the community. The final recommendation was that they should have a community discussion about this. In the past few years, ICANN Board members had participated at RIR meetings, which was a huge improvement and something they needed to build on.

D.1 Current Policy Topics - Global Policy Proposals

This presentation is available here:
https://ripe76.ripe.net/presentations/85-RIPE76_APWG.pdf

Sophia Silva Berueunger, APNIC, said she was in Panama a few weeks earlier when they had talked about the global registry proposal. There was some discussion about how this would affect ICP-2 [Criteria for Establishment of New Regional Internet Registries]. She asked if ICP-2 was really considered a global policy and if an RIR policy forum was really the place to discuss the creation of a new registry.

Filiz said the ASO AC’s website officially listed ICP-2 as a global policy which was in place, but from ICANN’s side they viewed this as something they needed to attach to the Number Community and there was no other place for them to define this.

Gert said the Address Policy WG in the RIPE region traditionally did all of the policy work. If it wasn’t related to numbers, you could have other policy proposals in other WGs. A policy change that would go into the creation of a new registry would be too big for this WG – so there would be the RIPE community list and the RIPE Chair to steer this discussion.  

Hans Petter noted that on ICANN’s website it said: “The following Internet coordination policy is being posted for the information of the Internet community.”

Dmitry said he hoped the chairs read the text and understood what the real goal was, that was trying to be expressed in such an exotic form. The idea behind the proposal was a “one-stop-shop” but the proposal created a mess around the establishment of a new RIR. He thought all of this discussion shifting to ICP-2 was a mistake.

Gert said they didn’t need to discuss this here.

D.2 Current Policy Topics

Marco Schmidt, RIPE NCC Policy Development Officer

This presentation is available here:
https://ripe76.ripe.net/presentations/57-Current_Policy_Topics-RIPE76v2.pdf

Jordi Palet Martinez, The IPv6 Company, said he had a clarification about the PDP changes in the LACNIC and AFRINIC regions. If you read the LACNIC PDP document, it said that consensus was only counted in the room at their meetings, while in practice what was said on the mailing lists also counted. He had initially proposed a very simplified proposal that updated their policy so that consensus was only determined on the mailing list as in the RIPE region, and also stating that the chairs had two weeks to make a determination of consensus rather than having to do it in two minutes in the meeting room. This proposal had not gone well on the mailing list, so he decided to present another one, which was about measuring the consensus on the mailing list and in the forum. This one had gone well and was in Last Call. 

At AFRINIC it was the same situation – they were only measuring consensus in the meeting room, and the policy they were discussing was still having the same problem. At their meeting it was discussed again but it was not called for consensus. He suggested both on the mailing list and during the meeting that they shouldn’t remain with text in their PDP which was not clear about taking the mailing list into consideration. So, it looked like they would soon be more aligned with the RIPE region, but would determine consensus both on the mailing list and at the meeting.

Erik Bais, A2B Internet, said there was a proposal to modify the PDP to allow the Review Phase to be extended, when needed, to allow for more comments. He asked how this affected current policy proposals – did they need to wait for the PDP to be updated, or could they extend a Review Phase already if they wanted to?

Marco said this was already a current practice and the proposal was about updating the PDP to make it consistent. It would therefore not affect ongoing policy proposals.

End of first session.

E. Feedback from RIPE NCC Registration Service (+ discussion with the group)

Andrea Cima, RIPE NCC

This presentation is available here:
https://ripe76.ripe.net/presentations/79-Andrea_Cima_APWG_Final.pdf

Erik Bais asked how much “IPv4 dust” [remaining addresses after exhaustion of the available IPv4 pool] Andrea was talking about.

Andrea said less than 5,500 IP addresses. There would be five LIRs that would receive bits and pieces. One option would be to add these addresses to the temporary pool to get them out of the way.

Erik asked if Andrea had considered allowing people to use them for research purposes. He asked if this would require a policy change.

Andrea said this was one possibility. The policy today said they had to issue /22s as one aggregate block and then later in smaller bits that added up to one /22. In the past, they had been given a mandate from the community to add addresses to the temporary assignment pool and so this wouldn’t need a policy change.

Lars Liman, NETNOD, suggested that whatever policy they develop should not aim at cementing the use of IPv4 but rather encourage IPv6.

Sebastian Wiesinger, Noris Network, said this should be put away somewhere and if people needed it for reasons that didn’t involve being routed on the global Internet, they could ask for it. As most people wouldn’t be able to us these addresses, he supported putting them away for special or experimental purposes. 

Gert said this sounded like the temporary pool. People could get a /29 from the pool, use it for a few months and then return it without a policy change being needed. 

Sebastian noted that Andrea had mentioned that the largest assignment from this pool had been a /15.

Andrea clarified this was the largest total amount given out at one time, which had been in multiple assignments to different entities.

Jordi suggested reducing the temporary pool to a /15 and having that dust go into the temporary pool. This could free up more space for real usage.

Erik asked if an increase in the IXP pool could come from the temporary pool as well.

Andrea said this could come from anywhere, but it would require a policy change as it mentioned they had a /16 set aside for IXPs. They still had around four years of IPv4 remaining for IXP peering LANs.

David Farmer, University of Minnesota / ARIN AC, said Andrea had asked if a waiting list was useful. He thought that was the wrong question. The purpose of a waiting list was to ensure that no IPv4 remained with the RIPE NCC, and it was a fair way to push those resources out. It wasn’t effective, but it made sure the resources didn’t get stuck, which was a good policy intent.

Tahar Schaa, consultant for the German government, said they needed to make priorities in terms of what they wanted the last IPv4 addresses to be used for. From his perspective, IXPs were part of the core infrastructure of the Internet. They might want to have them running as long as possible. Perhaps it would be wise to think about increasing the IXP pool and getting these addresses from the temporary pool.

Erik said that as Andrea had noted they needed a policy change on this, it might be worth having a discussion with the Connect WG to see what they were thinking.

Gert said he was hearing that they needed to take care of this and ask the Connect WG for its input. The question was what to do with returned addresses - they would need some mechanics for how they could distribute the remaining pieces in a good way. They might also get more addresses from IANA.

Andrea added that around 500,000 addresses were returned to the RIPE NCC each year. If they kept things as they were, organisations would join the RIPE NCC, become an LIR, and join a waiting list. LIRs would still expect a /22, so there would be no change to the size.

Erik asked if they could close the request functionality in the LIR Portal as soon as the RIPE NCC was out of IPv4 space, and re-open it when they had more. That would prevent a back-log of 2,000 LIRs who might not have a current need for addresses.

Andrea said the important thing would be to clearly communicate everything.

David Farmer said they needed to think about the fairness of the RIPE NCC suddenly distributing addresses that went to to whoever got there first.

Peter said that one interpretation of a waiting list seemed to be that even if there was no demand and no supply, it was first-come first-served. Both scenarios were open for abuse and would attract people who would try to game the system.

Gert said the RIPE NCC could come up with some information about how it saw things from its point of view.

Andrea said this was clear and they could do some more work on potential solutions.

F. Discussion of Open Policy Proposals

2018-01: Organisation-LIR Clarification in IPv6 Policy

Jordi Palet Martinez / Erik Bais / Juri Bogdanov

This presentation is available here:
https://ripe76.ripe.net/presentations/86-RIPE-2018-01-v2.pdf 

Gert said that from a PDP point of view, the proposal had gone through Discussion Phase with some support and was now in Review Phase. The impact analysis hadn't brought any major surprises. So far on the mailing list, they had some comments on grammar – whether it was “a” rather than “an” LIR – and he considered that solved. But they hadn’t had any voices of support (or opposition) in this phase.

Tahar said he didn’t want to oppose the proposal, but he had thought about why it was originally “organisation” rather than “LIR”. If you thought about a large ISP, the LIR was not the ISP – it was a department of that ISP. The criteria did not refer to the organisational structure of the LIR but rather the organisational structure of the whole ISP. Perhaps the proposal was okay, but perhaps it was a little bit weird for organisations that had this kind of self-understanding.

Jordi said in that case they would need another policy for IPv4 to bring the two policies into alignment, because it wasn’t fair that they should have different situations between the two. And they might also need a policy change for organisations of a previous organisation that already had an LIR.

Gert said he had some historical context. The original IPv6 policy from 20 years ago was a global policy. As the other RIR regions didn’t have the term “LIR” in the sense that they used it, the original text had said “organisation” without ever defining what it was. With LIR it was very precise, in terms of which contract was covering it. All of the policy text that was originally developed in the RIPE region already said LIR, except for this one piece they had inherited from the old days.

Tahar said perhaps they were changing history with this organisation term. With IPv4, it was always understood that an LIR was an ISP, with its own network infrastructure. But with IPv6, other organisations were becoming LIRs that might not also be ISPs. Perhaps it was not so clear that LIR and organisation were not the same and they could include a comment to this effect.

Gert said that LIR was a well-defined term that had a well-defined contract, and there had for years been non-ISP LIRs such as NICs and IXPs, so he didn’t think this was a strong argument.

Gert said this didn’t look like strong opposition, but they should go back to the mailing list for more feedback.

Peter said he had just looked at the text again and thought there was a different use of language that was not fixed by a policy proposal. Some text talked about “being” an LIR and in other places talked about “having” an LIR. Until they clarified what was meant by the difference between the two, more research would be needed.

Gert asked him to send this to the list.

Assignment Clarification in IPv6 Policy

Jordi Palet Martinez

This presentation is available here:
https://ripe76.ripe.net/presentations/90-RIPE-2018-02-v1.pdf

Raymond Jetton, ELIZA, speaking for himself, said he had one comment on the temporary parts. If they were talking about a “non-permanent” assignment, he would prefer that it specified that the end user didn’t know or have any control over which block or IP they used – because if you did that they had an assignment. If any other case, it was temporary address.

Jordi replied that that they were using a different terminology to avoid confusion, which was persistence. If a student was coming to the university every day and getting an address – was that an assignment?

Raymond said if he didn’t know which IP addresses he was getting, then it was not.  

Maximilian Wilhelm, Freifunk, said he had written some of the text that was being replaced. He referred to slide five and said they didn’t change anything on the IPv4 policies anymore, so that was done. On the first point, there were different views. They’d had two years of discussion and the consensus seemed to be that they should include data centre setups, which included permanent assignments for VMs, and he really wanted to keep those.

Jordi said the question was whether sub-assignment in the policies was blind to the concept of registration, or not necessary, because that changed things.

Max said he thought the first impact analysis from the RIPE NCC had covered the point of registering sub-assignments in the database, and they had all concluded that this was ridiculous on a /64 level or something, and then the topic had never come up again.  

Jordi said maybe that required some clarification from the RIPE NCC, as he still didn’t have a clear view after having discussed this in the five RIR regions already.

Gert said there was a clear answer to the question of whether they should care. The policy text should reflect the consensus of the region. Whether someone did something within their network that was not according to the policy text was another issue. But whatever they agreed was their intent should be in the policy text. Declaring that they didn’t care what was in the policy text didn’t send the right signal.

Jordi said he was saying that if sub-assigning without registration was not considered by the RIPE NCC as a sub-assignment, then they didn’t have a problem. 

Erik said the RIPE Database didn’t allow people to sub-assign PI space.

Gert said policies were also about giving guidance to people on how to do things. If it said not to go there, that was clear guidance.

Peter said Jordi was addressing an important aspect of this, but his flight-level was far too low and his speed far too high. He couldn’t imagine they would make registration in the RIPE Database dependent on whether the researcher had a six-month or a yearly contract. He thought they needed a discussion at a much higher level about what the purpose of the RIPE Database was. They had the law enforcement community coming in with different ideas about registration. He thought they shouldn’t spend more time on these details but rather go back to the bigger picture and think about what the purpose of the information in the database was.

Jordi asked if Peter thought they were missing a good definition of sub-assignment.

Peter said he was talking about an even higher-level discussion.

Gert said they’d had comments from three different people on the list who were unhappy for different reasons. He thought they should take another step back and work out what they were trying to achieve. He said Jordi should have further discussions with the WG before he worked on any new text.

Fixing Outdated Information in the IPv4 Policy

Andrea Cima, RIPE NCC

This presentation is available here:
https://ripe76.ripe.net/presentations/80-Andrea_Cima_2018-03_Fixing_IPv4_Policy_final.pdf

Daniel Stolpe, Resilans, asked if they were going to keep the Allocated PI/Unspecified at the RIR level and not at the LIR level.

Andrea replied that they were.  

Rob Evans said RFC 1918 was also known as BCP 0005. If the RFC was ever updated, the BCP number should stay the name.

Andrea said they could reference the BCP number.

Peter Koch said he had previously suggested that these be updated when the document was touched for another reason. But just upping the RFC number might also change the meaning in the text. He wanted to reiterate that they should to re-read the document being referenced when they made these updates.

Erik said the Discussion Phase ended on 23 May, so that was one more week.  

Y. Open Policy Hour

Sander recommended they discuss what they were trying to achieve rather than specific policy text at this stage.

Jordi said he didn’t think the policy was clear enough regarding what was considered a sub-assignment. Many people had been telling him to look at this, and he’d received a lot of private emails on the subject.

Radu-Adrian Feurdean, Coriolis Telecom, said they could ask why they had PA/PI and whether this could be fixed. Some of it involved money – there were organisations that couldn’t become LIRs or didn’t want to pay the membership fee. Others could easily pay the membership fee and should become LIRs no matter what, even if they only needed a /48. In some cases, IPv4 PI was used by organisations to provide services – organisations did this because they didn’t feel they were large enough to become LIRs.

Jordi said this confirmed that something was broken in the policy. The reason they had PI in IPv6 was because they had it in IPv4. If they adopted this policy, the differentiation on the cost between the two would need to change, because having a /48 shouldn’t cost the same as a /32 in terms of membership. He didn’t think they needed to consider the problem of the price, as this was out of scope for the WG.

Sebastian said he was having a problem with the term LIR-as-ISP, as there were LIRs that weren’t ISPs and they also needed to consider them (he worked for such an organisation himself). They had a well-defined term, he didn’t think they should make this smaller by saying that there were ISP-LIRs and other LIRs.

Jordi agreed. He said they shouldn’t look at the concrete text he had come up with. The goal was to remove the concept of “End User”. Maybe it was easier to say that you were just an “end site” –  and that made the difference. A regular LIR was not an end site – and the others were just end sites.

Sebastian said he didn’t see the benefit from this change if the status quo was fine.

Erik said it was different, as you had contractual agreements you would need to adjust. There were some companies, such as UN-type organisations, that couldn’t enter into contractual agreements with the RIPE NCC. Costs and contracts were the two main reasons why PI was originally introduced.

Jordi said it was a matter of fixing those agreements, and it wasn’t something they needed to address now. There was nothing to stop them from saying they were removing the End User agreement and making a modification to the LIR agreement.

Erik said if the end result was going to be similar – namely an LIR that had network and infrastructure vs an End User organisation – what were they fixing here?

Jordi said  they would be making the policy simple, by making a single contract that simplified things.

Lu Heng, Larus Cloud Service, said he supported the idea of getting rid of PI, as IPv4 PI had been subject to a lot of abuse over the past decade, which had created a mess in recent years. Getting rid of it might streamline the database and make it cleaner and easier to understand for outsiders. He understood Erik’s statement that some organisations might not be able or might be unwilling to enter into an agreement with the RIPE NCC, but that was a legal issue and they could let the lawyers deal with that part. If space needed to be mobile, they didn’t need PI to do that, they could have a transfer policy to move address space from one provider to another. He supported getting rid of the distinction between PI/PA to make the database easier to understand and manage.

Jordi said he wanted to add that they all knew there were people who were using PI to offer services – he asked if they wanted to allow that – otherwise they needed to do something about it.

Gert said he wanted to echo Peter’s earlier comment about flight level. They didn’t even have a problem statement yet or even agreement on what the problem was. It was therefore too early to discuss specific policy text until they agreed what the problem was. If the problem was that people were misusing PI or that PI was too cheap or too expensive or that the policy was too complicated, that should be agreed on first. Then they could take the next steps on deciding how to fix it. If the problem was that PI was too cheap, then they could pass this to the GM to solve. So first they had to agree what the problem was. Gert thanked Jordi for taking his idea to the WG.

Gert thanked the WG attendees for coming and helping to shape RIPE policy.

End of second session.