RIPE 71 Address Policy Working Group Minutes

Chairs: Gert Doering, Sander Steffann
Scribe: Antony Gollan (RIPE NCC)

Session I - Wednesday, 18 November 09:00 - 10:30
Session II - Wednesday, 18 November 11:00 - 12:30

Session I - Wednesday, 18 November 09:00 - 10:30

A. Administrative Matters

Gert Doering welcomed attendees and introduced his co-chair Sander Steffann. There were no changes to the agenda and the minutes from RIPE 70 were approved without comment.

C. Current Policy Topics

Marco Schmidt, RIPE NCC

This presentation is available at:https://ripe71.ripe.net/presentations/81-Current_Policy_Topics-RIPE71.pdf

There were no questions.

F. Discussion of Open Policy Proposals

Gert reminded attendees that no decisions were made in the WG session – they were made on the open mailing list.

2014-03, Remove Multihoming Requirements from AS Number Assignments

Nick Hilliard

This presentation is available at:https://ripe71.ripe.net/wp-content/uploads/presentations/92-inex-ripe-apwg-bucharest-2015-11-18.pdf

(Before Nick began his presentation) Gert clarified that the proposal 2014-03 had been formally withdrawn the previous week, mainly because it wasn't moving forward. He said there were arguments about how open the policy should be. They had hoped that the GM would solve this issue for them by introducing a charge for ASNs, but it had decided not to do this. He said that immediately after the proposal was withdrawn, people started talking about how they needed to have a policy like this. He said that Nick had volunteered a new version of the proposal and handed over to him to present.

David Huberman, Microsoft, thanked Nick for coming up with the proposal and asked that he consider having this as two separate policy proposals, as there were two issues that he didn't want to be conflated. The first was whether someone needed an ASN to run their network. The second issue was around the RIPE NCC's management of two ASN pools and the situation was going to change over time.

Nick said this created a lot more work and he would talk with David offline about this.

Brian Nisbet, HEAnet, asked if there was a danger that putting in place things to delay 16-bit ASN run-out would mean that the IETF put off addressing the 32-bit ASN issue.

Nick said the IETF was in denial about the 32-bit ASN issue and he had tried to bring this up several times but they wouldn't listen. He couldn't understand why they wouldn't address it and said it had turned into a real mess. He said he didn't think what the WG was doing would have any effect on the IETF whatsoever. He said the Wide BGP Communities proposal he had mentioned earlier had been proposed several years ago but it was very complicated, there was no running code, and it made things difficult for vendors. At best it would take several years before it was standardised.

Elvis Velea, v4Escrow (via remote participation), agreed with David that two proposals would be better than one.

Sander said this could make things very complicated.

Andrew Dul, speaking for himself, asked how they defined run-out.

Nick said you plucked out a number based on what seemed sensible.

Ingrid Wijte, RIPE NCC, said there were 3,900 16-bit ASNS remaining in the RIPE NCC's pool and this would last for 36 months at current rates.

Sander referred back to the IETF issue with 32-bit ASNs. He asked how many people in the WG would be in favour of putting together a joint statement from the WG to the IETF about this issue. The WG supported the idea.

There were no more questions.

2015-04, RIPE Resource Transfer Policies

Erik Bais

This prebsentation is available at:
https://ripe71.ripe.net/wp-content/uploads/presentations/90-2015-04-RIPE71.pdf

Gert gave an update on the status of the proposal, noting that in the impact analysis prepared for the current text there was a wording issue that could be read ambiguously by people outside of the community. He said they could still discuss the proposal knowing that an updated version was on the way. He said having duplicate text across various documents was not good and there was a lot of historical baggage around why this was there.

Peter Koch, DENIC, said these editorial changes were risky and seemed to create a trap. He suggested having a tutorial document that provided an explanation while the policy document was the authoritative version. He preferred to stay where they were but invest the effort to provide explanations to people. He said that changing the policy just to make it more accessible didn't convince him.

Gert said they had done document clean-up in the past and it was painful, but was worth the effort. He said they couldn't just do nothing here. If they didn't want a joint transfer document, then they would have to ask what they wanted to do with the inter-RIR transfer document and maybe split this up and integrate it into the three separate policies.

Peter said he doubted that the presence of an inter-RIR transfer document was inconsistent, because policy was defined intra-RIR on a per-object basis, which was fine, but then you also needed to have something that defined the external relations when resources crossed the RIR boundary.

Gert replied that if they wanted to transfer to a RIPE LIR they went to Document A, and if they wanted to transfer to an ARIN LIR they went to Document B. He said he didn't think they wanted this. He said they could keep this in the existing IPv4, IPv6 and ASN policies, but they would have to do a clean-up either way.

Peter said you could construct this inconsistency both ways. If he was interested in IPv6 he'd need to go to two documents: one for allocations and assignments and one for a transfer.

Gert said the question was whether they wanted to merge inter-RIR transfers into the policies for separate resources, or to move the transfer bits out into a process document. He said he didn't think they could just do nothing, because the documents were not good right now.

Elvis (via remote participation) said the best option was to first do a clean up of the existing documents and move all of the transfer-related parts into one document, then do additional changes using further proposals, merging all the documents together and moving other things in there.

Sander said this was a slightly different discussion so they should keep it for later.

János Zsakó, Hungary, said he didn't agree that the inter-RIR policy was inconsistent, as there were intra-RIR transfer rules and the inter-RIR proposal complemented them.

Erik agreed and said the inter-RIR policy was different on its own. By going through with the clean-up, they would have the first “functional” policy document, and this would be different approach to what they had done in the past. He wanted to know if the WG was aware of what he was doing here, and if it supported this approach. When he had first proposed a clean-up and having everything in one document it made sense, because it would make life easier for everyone. He said this would be especially relevant in the future as transfers became a more important aspect of policies and more people would be looking for this information. He said they could do it either way where they had better informational stuff on the website instead.

Sander said having multiple copies of similar text could result in diverging interpretations.

Andrew Dul, ARIN AC, said that in the ARIN region they had merged all of their policies into one document that was edited and revision controlled. He said he just wanted to point out this approach.

Ingrid noted that the RIPE NCC already had a section on its website that provided in-depth information on transfers. She said that part of the conversation was already finished and they needed to focus on what they wanted to do with the documentation.

Erik said there were some changes in the current version, specifically with the introduction of a holding period for mergers and acquisitions, and also around transparency. In the impact analysis, the RIPE NCC had asked what they wanted to do around unapproved transfers, as this number wasn't going to change. He said that the RIPE NCC had also done a good job in the impact analysis specifying its interpretation regarding a holding period for mergers and acquisitions and they really wanted to get some more input on these points on the mailing list.

Elvis (via remote participation) said he thought they needed to move along with one document.

Randy Bush, IIJ, said he had introduced a policy proposal in the APNIC region to be the last proposal. He said the policies that RIPE had at the moment worked and they didn't need any more proposals.

Gert thanked Randy for his comment and said they hoped to wrap up all of the policies soon.

Erik asked people to check out the policy proposal and the bits that were actual changes and give any comments as they moved forward on the list.

There were no further comments.

2015-05 Revision of the Last /8 Allocation Criteria

Radu-Adrian Feurdean

This presentation is available at:https://ripe71.ripe.net/wp-content/uploads/presentations/66-2015-05-RIPE71.pdf

Erik said the reason they had originally wanted a /8 policy was to allow people to offer IPv6 and to do this via a Carrier Grade NAT so that they could provide connectivity to IPv4. If people were not using this IPv4 in the way it was intended, then nothing would help them as they would still run out eventually.

Radu said they had not run out yet. He said if their intention was to have a CGN, then perhaps they could update the policy to say this explicitly as ARIN had done.

Erik agreed that maybe they needed to change this in the policy. Changing the /22 pool into something else would prevent newcomers from being able to join the community. He said it was about giving the next Twitter or Facebook the opportunity to participate.

Radu said a counter-argument was that most Internet companies started by taking transit from someone else, as opposed to scaling up from PI resources. He said this was why people became LIRs – they wanted to be independent and no longer wanted transit from someone else. Regarding new entrants, he said people said they wanted to preserve the pool until 2020 but his own data that he'd published on the mailing list indicated that they would be out of address space before then. He said his proposal should be a first step. The other steps should be to make the policy clear on other issues.

Elvis (via remote participation) said that considering the heated discussion, he thought the proposal would not reach consensus and he would not be a part of any future revisions. He didn't think that by adding more restrictions they would reach consensus. He said there were other people like Ricardo who could take over the work.

Hans Petter Holen, Visma, said he had travelled to a lot of regional meetings and met with new members. What he heard from them was that everyone could get one /22, and you could get many of them if you could afford it. He said he heard that money was their first thought and maybe one day they planned to deploy IPv6 – because currently it was expensive to do so and they didn't have it in their country. He asked if they really wanted the RIPE NCC to be giving out address space for cash.

Jim Reid agreed with Erik and said they were making mistaken assumptions that the situation they were in now with addresses was the same as it was five or ten years ago. He said possibly the system was being gamed by LIRs with money and he hoped they could address it if so. He said the current policy was equal and everyone shared the same pain. He said looking at who needed it more or who was using it in the right way was madness. He said it should be up to LIRs to decide how best to use their resources.

Radu said he didn't think the pain was the same for everyone. When you had a /10 you could scavenge unused addresses and get a /22 from that. He said it wasn't possible to do this with a /22.

Jim said these LIRs had gotten their allocations a long time ago in a different world. The best approach was to treat everyone equally. He added that there were legacy holders with /8s but there was nothing they could do about that.

Gert said they were running late but could continue the discussion after the break.

Wilfried Woeber, University of Vienna / ACOnet / VIX, said the last /8 policy was working exactly as intended. He noted Hans Petter's comment about favouring LIRs with money, but said the current situation was well defined, predictable, and gave businesses a planning horizon, which was important. When it came to the question of how much it cost to create an LIR to receive a /22, this was a GM issue rather than a policy one, and they should address it separately. To those who advocated burning through the remaining IPv4 pool, he added that he didn't see any indication that buying addresses in the mid-term was going to be much cheaper than the regular, predictable way of opening an LIR. He also said there was a contradiction in Radu's argument about the remaining IPv4 pool: either he wanted to have this last for some time or he wanted to burn through it quickly – he couldn't have it both ways.

Elvis (via remote participation) said he just wanted to clarify after his previous comments that he wasn't against the proposal – he just wouldn't be working on it and was happy for other people like Ricardo to take over his role.

End of first session.

Session II - Wednesday, 18 November 11:00 - 12:30

Gert welcomed attendees back and said they would stick to the agenda as published, and then return to discussion of Radu's proposal.

H. Romania's Jump to 1st Place as Exporter of IPs

Ciprian Nica

This presentation is available at:https://ripe71.ripe.net/wp-content/uploads/presentations/101-ripe71_presentation_romania_jump_1_ipv4_exporter.pdf

There were no questions from the room.

D. Feedback from RIPE NCC Registration Services

Ingrid Wijte

You can find this presentation here:
https://ripe71.ripe.net/wp-content/uploads/presentations/86-FeedbackRS-RIPE71.pdf

Regarding the reports of End Users being “strong-armed” into buying the PA assignments they had been using, Ingrid clarified that organisations would need to become members of the RIPE NCC to assume holdership of PA space.

Erik asked if Ingrid could provide some numbers about how often this was happening and how many LIRs were doing this. He said these organisations were moving out of the game and while it was part of an exit strategy, it should be frowned upon. He understood that they couldn't interfere with businesses and it was a slippery slope, but he wondered what a possible solution was, as they needed to protect people who had been using the space legitimately for some time. He suggested having a wall of shame as a way to beat this.

Ingrid said they received around five emails a week regarding this practice. She noted that these emails came from the End Users, so she couldn't say for sure what the LIRs were telling their customers or what the exact circumstances were. She did want to note that to a certain extent it was hearsay. She said she supposed this was about self-regulation, with ISPs wanting to do the proper thing for their industry as a whole. Before publishing names, they would need to have clarity on the issue and not just the End User's word.

Erik said he wasn't actually serious about the name and shame approach – that was just one way of tackling the issue that instinctively came to mind.

Ciprian Nica, IP Broker Ltd, disagreed with Erik. He said he often saw cases of PA assignment holders that asked him to help them sell their addresses. He had to inform them that just because they rented an apartment, didn't mean they owned it – they had a contract with the LIR. He didn't think there was anything that RIPE could do as they had contracts and they shouldn't shame an organisation for wanting to get out of the business.

Erik said he understood that it wasn't up to them to get involved in the business of LIRs, but they had been strong-arming organisations, and while it wasn't something that they as a community could solve, if they could get some more insight into this, then maybe there was something they could do to protect customers. He agreed that it was a tricky situation.

Ciprian repeated his apartment analogy. He said that if the rent went up, the tenant couldn't say they wanted to pay their previous rent for the rest of their life. He said the LIR wouldn't do anything outside of the contract and at the end of the day it was about a contract between two entities.

Gert said at the end of the day, it came down to a contract that might have been created 10 years ago – and while it might not be a nice thing to do, if the contract said it had to be renewed every year, the LIR was within its rights not to renew it.

Elvis (via remote participation) said even the RIPE NCC Template End User Agreement said that the LIR could update the contract. He said most likely Erik was talking about complaints he had heard from upset customers and this might not be the entire truth.

Cristian Haja, JUMP Management, said he was possibly the person who knew the most about this situation. He said his organisation had done the rental for perhaps 90% of the neighbourhood networks in Romania. They knew for sure that many of these organisations weren't using the IP ranges properly and had a lot of free space. He said they had found a few methods to solve this. They offered them an allocation for free and said they would not charge them any fee if the RIPE policies did not change. But when they reached the last /8 and could not receive any more address space from the RIPE NCC, they put in place a 30 EUR fee per year. Then, IPv4 transfers became possible. So they decided to look at how many IPs were in use and how many were being used for illegitimate business and cancelled many contracts with customers that were involved in spam. They also looked at IP addresses that were not being announced and cancelled those contracts as well.

Ingrid said she just wanted to clarify that “not announced” did not necessarily mean “not used”.

Cristian said they eventually reached a certain point where they found they could no longer get IPv4 and so they decided to have an annual fee closer to 125 EUR per year, which they thought was reasonable for a /24. At this point, they had received a lot of complaints saying they were small businesses and couldn't afford this. But many of these customers weren't using all of their space, so they said they could release the unused space that they didn't need and transfer the rest of it to their LIR or transfer it to another LIR, so that they became independent of JUMP. He said at this point many customers wanted to do this and some did not. He said probably for these organisations it was best for them to become an LIR and secure their business. But some organisations didn't want to pay this fee, so for these clients it was clear that JUMP would not keep their contract with them.

Ingrid said it was good to hear the story from the other side.

Cristian said that was the case, and many of the new LIRs that had started in Romania recently had done so with JUMP's help.

Ciprian said he also wanted to note that Jump had given out over half a million addresses for free to small businesses in the country, so that needed to be applauded – as he didn't know of any other LIRs that had done this.

Gert said he appreciated this and had noted it in his presentation. He said what he heard was that it was a fact of life, though it might not be to everyone's liking. He asked the RIPE NCC to keep an eye on this and keep the WG informed even if it might not be able or willing to do anything about it.

Ingrid said they would do this.

Ingrid moved to the topic of LIRs holding unspecified/allocated PI blocks due to being last resort registries. She said the IPv4 policy said these blocks were aggregated but not PA, as there were no contracts made at the time regarding what happened when someone changed LIRs. She said the IPv4 policy recommended that these blocks be converted to allocated PA where possible, which created a different approach between the different types of addresses.

Erik asked if the majority of this space had been handed out by RIPE NCC or if it was legacy.

Ingrid said that these were last resort registries that had received space from InterNIC. When the RIPE NCC was founded, organisations were given the option to keep these as allocations in the system, or to return them to the RIPE NCC. In the transition phase, a lot of last resort registries had to forward their requests to the RIPE NCC to further process.

Gert added that some of these blocks came directly from the RIPE NCC.

Erik said if these companies received these prefixes directly from IANA then it was better to give them the option to change its status to legacy or to allocated PA.

Ingrid clarified that this space was from InterNIC and not IANA. She noted that InterNIC was the predecessor to the RIPE NCC, and so it was a little bit more complex than some of the legacy /8s that were given directly from IANA to resource holders. When that transition was made, agreements were made with these parties, and the definition of legacy or not-legacy was made at that time. She said they weren't sure if they could override those agreements.

Elvis (via remote participation) said he would think that users with assigned PI from an LIR should be able to move LIRs as if it was assigned PI from the RIPE NCC.

Ingrid replied that this depended on the agreements that the LIR had made with the End User. The RIPE NCC was not aware of the content of these agreements, so couldn't make this decision on behalf of the LIR that held the parent block.

Cristian asked what happened if there was no contract between the End User and the LIR.

Ingrid replied that the LIR was responsible for that parent block as this was formalised through the hierarchy in the registry system.

Cristian said that the End User request to the LIR for the PI assignment was approved by the RIPE NCC through a ticket that had a number. While there was no contract, practically the End User would think that this was PI that was approved by the RIPE NCC because they sent them registration documents and other information.

Ingrid said the RIPE NCC's approval followed a similar process as for assigned PA. They had not created separate entries for those assignments, they came out of that block from the LIR.

Cristian said that at some point the End User would think that it was between the RIPE NCC and the LIR.

Ingrid said this was why they were bringing it up, they were referring the End User to the LIR, as they were next in line and they had a business relationship with the LIR.

Cristian replied that the LIR would say no.

Ingrid said the RIPE NCC couldn't judge agreements that were made, except for those that were made from the RIPE NCC's allocated PI, because the rules had been defined when they made those assignments. She added that for the cases being discussed, they didn't know the content of any agreements that were made. She agreed that there was confusion there when they got those questions.

Gert said he was in the same camp as Cristian and wanted to challenge the RIPE NCC's interpretation. He said the LIR had made the decision to stamp this as assigned PI. He said he thought it should be treated as if it were assigned PI and independent of any contracts. Or he thought that they should go out and find these contracts, so he thought 2007-01 applied to this space, but this was his personal view. He said they might want to revisit their whole interpretation internally and talk to the affected LIRs.

Ingrid said this was why they were bringing it up.

Sander noted that PI stood for “provider independent” and said it should mean that.

Ingrid said this was partly due to the fact that this was something that people decided for themselves at the time when the status was introduced and some people may not have made a conscious decision. She said the decision that was made at the time of the assignment was not something that the RIPE NCC was aware of, and in some cases the resource holder wasn't aware either.

Wilfried, as manager of their LIR since 1993, said he thought they were mixing a couple of things – the status of an address block on one axis and the timeline on the other. He said in their case when they'd gotten their block to do assignments from the RIPE NCC by way of the regular IANA RIPE NCC local registry, this was before the distinction between PI or PA was made. As they only distributed IP addresses to customers of their operations, they agreed early on with the RIPE NCC to re-label from undefined to PA. At the same time, there was the last resort registry in their country. On purpose, that big address block was managed by an entity that later became an LIR, but it was inherently managed as a PI block. He said the option to re-label all of the blocks to PA was not going to fly, as it would fail for those registries that had been last resort registries. He said they were also oversimplifying a bit – if they went back a year or two – even when the RIPE NCC was in existence, there was still a parallel path for obtaining addresses – which led to the ERX project. He said that everything that had been distributed outside of the RIPE NCC food-chain had to be labelled legacy.

Ingrid said that at the beginning of the legacy policy implementation, they had looked at the number of blocks that were relabelled as legacy but she didn't have this available right now.

Wilfried suggested some of the old people that were involved get together with the RIPE NCC to create a chart that looked at what they had wanted to achieve at the time. He said it was a little more complex than they had in their heads at the moment.

Daniel Stolpe, Resiliens, said they were running this sort of a last resort registry in Sweden. He said his board even didn't know you could have something called allocated PI. He said these addresses had a very special history and had been used in a legacy-ish, PA-ish way. They didn't have any statement at the time and it wasn't as simple as giving them the status allocated PA. He agreed with Wilfried that the people involved should talk with the RIPE NCC to see what they could do about it.

Ingrid said one option was to keep things as they were.

Radu agreed that they shouldn't convert the superblocks to allocated PA. He said there were blocks that had been given out as allocated PI and there had been a conscious decision to label them this way.

Elvis (via remote participation) said as far as he knew, when PI assignments were made in the old days, the LIR would request an approval from the RIPE NCC for the PI assignment to the customer. The decision of whether the PI would come from the RIPE NCC or the LIR was not transparent to the customer. He said the customer had received the PI and should be able to move it anywhere. He said he didn't think that the RIPE NCC's interpretation was correct.

Erik said he saw in their own system they had 29 entries of different companies that basically held some form of allocated/unspecified, so it was a fairly small set of companies, the majority of which were present at the RIPE Meeting. He said when they looked at allocated PI, there were only nine different companies that were doing this, one of which was the RIPE NCC itself. He said the impact of this was very small – it was less than 40 entities, all of which were members. He said the question was how long were they going to debate this, as he thought most of them were in the room and they could do it face-to-face. He said this shouldn't take as long as 2007-01.

Elvis (via remote participation) said a solution was for PI assignment holders being able to sign a contract with a sponsoring LIR and to keep it as PI. PI space that was not registered as PA could be deaggregated and changed into allocated PA or assigned PI to the LIR.

Ingrid said it wasn't up to the RIPE NCC to make this decision on its own.

Hans Petter said they had two different classes of addresses with different properties. Portability between ISPs was one aspect, being able to make assignments to your customers was another. As most of the people in the room weren't affected by this, he suggested they get these people together in a room and ask them.

Ingrid said the RIPE NCC was willing to sit down with those block holders. However, she said it was worth having the community at large reflect on the outcome of those discussions, as allocated PI blocks could potentially have a greater value than other types of addresses. She said it would be important to report back before any final decisions were made – similar to what had been done with the legacy proposal.

Gert said he thought the points from Hans Petter and Ingrid were good closing remarks. He said the reason that he was so interested in this was that there was confusion being caused by the fact that there were different types of addresses called PI. He said the decision to round up the affected entities and come up with a strategy and present this to the WG sounded like a good action item for the RIPE NCC.

There were no more questions.

2015-05 Revision of the Last /8 Allocation Criteria (Continued Discussion)

Radu-Adrian Feurdean

Gert said they still had five minutes remaining to return to their discussion of Radu's proposal. He said it had been noted that people circumvented the policy by opening additional LIRs. He said there wasn't much the WG could do about this, but it could be addressed by the GM, and recommended that members voice their opinion there if they felt strongly about this.

Sander said that one of the things that had started this discussion was the graph that showed that the IPv4 pool wasn't shrinking, but this was just only because of one-off allocations from IANA and there wouldn't be more in the future.

Radu agreed and said that while he knew this, many others didn't. He said that when he entered his proposal into the PDP, he had received mostly private responses.

Erik said that before the break, Radu said he expected the IPv4 pool would run out in less than five years. He said that if they followed this line of thinking, shouldn't they change the policy to limit allocations to a /23 instead of running out sooner? He said they would need IPv4 to last longer than five years.

Radu said he would've supported doing this a long time ago, like having a /16 or a /17 reserved. He said that when they reached a /10 or so, he would support removing the limits. He said no one outside of Europe (RIPE) was doing this.

Erik said that just because others weren't following the same approach didn't mean that RIPE's approach was wrong. Erik said that if the plan was for a long run-out, they needed to reduce the allocation size. If they wanted to burn through it quickly, then they should do as Radu suggested.

Radu replied that at some point they would run out one way or the other. He said that even if it was 10 years from 2012, it was too long. He said all the other RIRs, including AFRINIC, would be running out by then.

Sander said that the fact that other networks were coming to the RIPE region might be a sign that they were doing something good.

Elvis (via remote participation), said the price that mattered wasn't the price of the membership, it was the price of IPs in the marketplace that was hurting networks that only had a /22. Until they addressed this, the big players would have no incentive to move to IPv6, while the smaller organisations would suffer.

Gert said he didn't buy the argument of 10,000 LIRs complaining they couldn't have additional space compared to no new LIRs receiving any IPv4 space.

Sander said people kept forgetting that this address space was reserved for new members and maybe they needed to communicate this clearer.

Radu suggested that Marco include the graph from the RIPE NCC website in the future, which was clearer.

Gert said he didn't think they were going to reach consensus, but it was important to have the discussion, even if it had led to complaints on the mailing list. He said it was impossible to make everyone happy, but maybe they could make everyone equally unhappy. He thanked Radu and said they could continue the discussion on the mailing list.

Radu said he would see if he could come up with a new proposal version that addressed people's concerns.

Sander thanked Radu and Elvis for being brave enough to stand up and represent the proposal.

Radu said that while they had transfer policies for everything, everybody could see that the mergers and acquisitions process was subject to abuse. He asked if they could say that mergers and acquisitions were subject to policy.

Sander said he thought this was something that needed to be discussed in the RIPE NCC Services WG as well.

Gert said that mergers and acquisitions were originally an option because they didn't have all of the policies in place. However, now that this was done, he said perhaps this was something they could think about.

End of second session.