ARIN PPC at NANOG 63 Transcript - 03 February 2015 [Archived]

Note: This transcript may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting.

Opening and Announcements

John Curran: (No audio)…held by ARIN, facilitated by in‑person and remote participation. We hold these for two days at the ARIN Public Policy meetings and at other forums where the Board of Trustees asks. It’s not just the people in this room but remote participants. We have a webcast, live transcript, downloadable meeting material and online chat rooms, so they can participate.

Reminder, the Chair, in this case it’s Dan, will moderate the discussion so everyone can speak and be heard. State your name and affiliation when you approach the microphone. And please comply with the rules and courtesies outlined in the Discussion Guide.

Dan, could you hold up the Discussion Guide? You have one of these in paper. They’re available at the front of the room and they’re also online for the online participants.

Seated up here is myself, Paul Andersen, Board Vice Chair and Treasurer; Dan Alexander, the AC Chair, and Kevin Blumberg, the AC Vice Chair; and we have Jabber volunteers, Kevin and David Farmer, who will be helping us moderate the Jabber rooms.

Okay. We’re going to do a few things today. We have an update on the AC activities, which will be given by Dan, and then we have seven policy discussions.

Three of them are Recommended Draft Policies. These literally have the opportunity in the near future to be adopted and could end up in the Policy Resource Manual and be used by ARIN for how we administer the Regional Registry.

We have four Draft Policies, those are policies still being worked by the community and the ARIN Advisory Council. And when they get to a state where they’re ready to be recommended, they’ll become Recommended Draft Policies.

So having given you an idea of the day, I’ll turn things over to Dan so he can give a presentation on the AC activities.

Go ahead, Dan.

Update on Advisory Council Activities

Dan Alexander: As John mentioned, I’m Dan Alexander. I am the Chair this year of the Advisory Council, which is new because John Sweeting, who was on the AC for a number of years, took care of us as Chair.

So I’m the new guy. There’s 15 of us, elected to three‑year terms. And we’re tasked with facilitating this Policy Development Process. So we’re here to really get your feedback and listen to what you have to say about the different proposals that are being discussed, what you think is a good idea, which are bad, how you would like to change them.

There’s five of us here, as John covered. We have seven proposals to discuss today. Three of them are recommended. So this is at a policy state where the text is pretty solidified. And if everybody agrees and thinks this is a good idea, this is a proposal that we would typically move to the next step and recommend to the Board for adoption.

Four of the policies aren’t at that stage yet. They’re just draft proposals. So we’re here to discuss them and get more feedback as to how they would be changed, what you think is good and bad about each.

There’s also a policy breakout room after this discussion where, if people wanted to meet on a one‑on‑one basis and discuss this further, that is available to them.

And with that, we can jump right into the first one. David.

Recommended Draft Policy ARIN-2014-1: Out of Region Use

John Curran: Okay. So I’m going to do the introduction to the Recommended Draft Policy 2014‑1. And this is Out of Region Use.

So history of this, it started out in December 2013 as ARIN Policy Proposal 192. The shepherds are Milton Muller and Tina Morris. It’s been presented at a few places. It’s been presented at NANOG 60, 61 and 62. And it was also presented at the ARIN 33 and ARIN 34 meetings. It advanced to Recommended Draft Policy in December 2014. The text is online and in your Discussion Guide.

Staff understanding: So the policy would allow out of region use of ARIN-issued resources as long as the requesting organization is presently an ARIN registry customer and currently using the equivalent of a /22 IPv4 block, /44 IPv6 block or an ASN on infrastructure physically located in the ARIN region.

An officer attestation would be required to verify that the resource request being made to ARIN is not a duplicate of one made to another RIR.

So this literally would allow someone to come to ARIN and say “I need additional address space for my operations in someplace outside the ARIN region.” So outside the U.S., the Caribbean and Canada.

And we would issue address space for that purpose, presuming they were an existing ARIN registry customer. Currently we require justified need for resources to be based specifically within the ARIN region.

If you show up and say I have a need and it’s on another continent outside the ARIN region, we don’t consider that a valid basis for issuing address space.

This would change that. When processing resource address for use in another region, ARIN staff would include any address space registered through the other RIR.

So if you had a block in another region and you were applying for address space in that region, we would consider the address space you have in another region. This is new and might be a little bit complicated for us to implement.

It means we’re reviewing utilization of address space outside, because if you want address space for use in another region, we would now have to talk about why you need that address space.

We’re pretty familiar with how address space is used in the ARIN region, and sometimes local regulation, local infrastructure, dynamics affect how people have to use address space. I don’t know whether the regulations of the other 150 economies in the world might affect address space usage.

So reviewing whether you need address space in another region is, like I say, new ground. The policy would be placed in NRPM as Section 2.17.

And I’ll go through the legal assessment. Because this is new ground, there’s a few bullets for that. ARIN Counsel supports the issuance of resources to entities in the ARIN region that need number resources that will be used in this region and the remainder of the world.

ARIN currently issues resources to those needs based on needs methodology. The proposed policy now requires that there be a /22 in the ARIN service region or v6 or ASN. Once that exists, it allows all the recipient’s needs be met by the demand outside the service region.

There’s also now a requirement that they be an existing ARIN customer, which helps. So these are improvements from the last time we reviewed the policy.

However, there remains an issue in that we would be allocating resources entirely for use outside the region. And the fact that we’re doing that and those resources could be obtained by another RIR, presuming they had them, means we’re actually changing ARIN’s mission to some extent.

We’re changing the scope of our service and what we do, because historically we’ve turned down organizations who come to us and say I need an address block entirely for use where that use is entirely outside of ARIN’s region.

This is interesting, because the registry system has been around 15 years. It might be time for it to evolve. But we’re not doing that as a discussion with the entire global community and the five RIRs, we’re doing it through one policy proposal.

So that has concern because we don’t know the full implications. It’s inconsistent, in particular, with one policy, which is the Internet Coordination Policy 2, which is an ICANN policy.

And ICANN ‑‑ and ICP‑2, when you’re establishing a new RIR, says that that a new RIR has a service region and that service region should be exclusive for that RIR. Obviously this policy implies that we would not be following that.

Now, ICP‑2 is for the creation of a new RIR. Doesn’t say anything about an existing RIR. But if you imagine that there’s a constraint to creation that you have a service region, then it can’t go away an hour later. It’s got to exist for some amount of time. The question is does it exist for 15 years.

How long does an RIR have a stable service region? ARIN can’t perform the business functions in this if the requesters are in certain countries. Because we’re operating in the United States, we have US law and we have compliance with it, there are some countries literally, even if they made the request, we would be unable to fulfill. And we just note that regardless of the policy, we have to comply with the law where we’re operating.

Staff noted that it would have a significant resource impact. It would occur within five to six months after ratification by the Board. We’d need to update internal guidelines. We need to do staff training. We need to figure out the process for external reviewing need that’s outside the region.

And there’s some engineering to support out of region business rules. I’m now going to turn it over to David Farmer, who will do the presentation by the ARIN Advisory Council.

David Farmer: Okay. So just for full disclosure, besides presenting this, I’m the original author. However, the current text has no resemblance to what I started with. This is a good thing, actually. But okay.

So summary. There actually is one piece of text ‑‑ oh, problem sequence next. So John gave an excellent summary. This basically just reinforces all that.

And the important one here is right now as currently drafted, there is no requirement that you can actually have solely out of region need being fulfilled by ARIN.

And this is something we need to talk about. I’d really like to see some discussion on that. Is that needed or can we move along?

But the important piece here, this is text that didn’t change, is the problem statement. And that is the current policy neither clearly forbids nor clearly permits out-of-region use. It’s pretty much mute on the subject. There’s no guidance. Newbies come in and this is a question they always ask. And I’ve heard this asked and get so many questions about it.

But staff has been counting out-of-region use as in-region under certain circumstances dealing with when the prefix is routed in the region and various other things that aren’t clearly defined anywhere.

And so this adds to the ambiguity, personally. So summarizing the staff and legal review which is in your documents here. The change to the text since the last version, adding an in-region nexus has improved the proposal.

There’s still issues concerning ICP‑2. Council’s ‑‑ summarize the counsel’s fundamental issue is, hey, is this going to create more fraud?

As John mentioned, there’s questions about how this, as current text, how this deals with the other RIRs. This is an important question; but first, before we get to that, we’ve got to decide is this what we want to do? Because the easy answer is to not create that problem if we can fix the text.

But as a community, we’ve got to decide what we want to do. The important thing here, though, is under the staff and legal is that there’s no legal reasons to prevent implementation currently.

If this is what really we want to do, we might need to coordinate with the other RIRs, but there’s no legal reason we can’t do this.

A little about ICP‑2. As John mentioned, it defines the creation, the criteria for creating a new RIR. It’s ICANN policy. We can’t just unilaterally change this if we want to.

And then we need to talk about: Do we need to make some changes here to bring us more in line? The one thing I will add, though, is that ICP‑2 has a whole number of pieces to it. But one of the things it doesn’t do is it doesn’t directly talk about how resources are used. It’s about the creation of a new RIR.

So there’s a number of issues here on the slide here. Scarcity is driving the ‑‑ free pool run out is driving scarcity driving people, people that wouldn’t necessarily come to ARIN or coming to ARIN, this is what’s driven a lot of this.

And that was it. Let’s go back.

Paul Andersen: I’ll be your lovely Chair for the next few minutes. At this time we would open the mics and invite any comments, discussion, feedback on the proposal. Front microphone.

Lee Howard: Good morning.

Paul Andersen: As always, please remember to identify your name and organization.

Lee Howard: Lee Howard, Time Warner Cable. There’s three sets of addresses. I guess there’s four sets of number resources this would affect.

It would affect autonomous system numbers, presumably, because I believe it says numbers not addresses. But I may not be reading close enough. Hand wave.

It would affect IPv6 addresses. Not a big deal. I’m not terribly concerned with conservation of IPv6.

It would affect transfer requests. But I think with the inter‑RIR transfer policy, I think that’s mostly covered. And I’d like some clarification there, if we need this to cover anything not covered by the transfer policy.

And post‑ARIN free pool depletion, it would also cover waiting list requests, which would presumably get allocated from IANA-return space, and that’s a set of address space that I would be very worried about in this regard.

So there’s the technical concern that I have. I’m also very concerned about violating the principles of ICP‑2, because if ARIN can say we’re the RIR for the world, then why do we even need regional registries anymore, why couldn’t any other actor who wanted to start up an Internet registry start up an Internet registry overlapping ARIN’s service area or any other RIR’s service area? I don’t like that precedent.

Paul Andersen: There are two points there. Would you like to address number one and, John, if you want to do number two.

David Farmer: I guess the question I have or the statement I have is those are very valid points. Do you have suggestions on what you would like to see done about it? Like for the ‑‑

Paul Andersen: Start with the first point and comment. Because I’d like John to feed back on the second before we get too deep.

Lee Howard: I would go ahead and say that I think it would be a very bad idea to implement this proposed policy prior to free pool exhaustion. And I may want to hear John’s answer before I voice an opinion on the policy overall.

Paul Andersen: It would be useful if John would like.

John Curran: Could you, for sake of clarity, restate your second point.

Lee Howard: Second point was about ICP‑2. And if we violate, not the principles but sort of the guidelines, the ideas behind ICP‑2, then what’s to prevent anybody else who thinks that they ought to start up a registry overlapping the service region of an RIR from doing so?

I can think of some people who might be interested in doing that.

John Curran: So recognize the registry system operates because all of us are operating one registry, and at any given moment a given address block is under the administration of a single RIR or it’s in the free pool at the IANA, one of the reserve pools.

So as long as all of the registries coordinate, and there’s no two registries working on a single address block, therefore invalidating the uniqueness principle, as long as all the registries all coordinate and we know it’s one unified set of two to the 32nd bits, for example, then we can maintain uniqueness and everything is fine.

ICP‑2 established the process 15 years ago for establishing a new RIR, and it didn’t say how RIRs change service regions. It doesn’t say ‑‑ it says the service region shouldn’t overlap for purposes of avoiding confusion.

But note that we have the RIRs because of a convenience to the community. You want to work with an RIR who speaks your language. You want to have one that operates in your time zone.

So while it was seen the best way to do that is to have the RIRs and then eventually we added another one and ended up with four and ended up with five RIRs, that was seen as the best way to do it. That policy hasn’t been revisited in years.

The question that you’re asking is if we changed and we started servicing people outside the region, would we be violating ICP‑2.

It’s not clear ICP‑2 is applicable at anything other than RIR stand‑up. It has no provisions for ongoing aspects.

Paul Andersen: I invite others to approach the mic if they wish to comment, but I’d like to give you an opportunity to respond.

Lee Howard: My concern is that it could establish a precedent for others who would want to establish a new Internet registry and what would prevent anybody from saying: Let’s go to an all national registry forum? And there are reasons other than uniqueness for having regionally‑based registries.

So those are my concerns. And I think, I guess because what you want to hear is you know do you support or oppose. [Audio difficulties.]

John Curran: We should continue.

Unidentified Person: Should we speak louder?

Paul Andersen: Go ahead, sir.

Robert Duncan: Robert Duncan, Merit Network. I’m struck with the fact that this is or should be, in my eyes, primarily directed at an ARIN member who is not a member at another RIR that wants to use a little bit of resource in rest of world.

If it’s multi‑national, with registration in multiple RIRs, why don’t they just transfer some space and claim it in the other RIR? It would seem a cleaner policy to me. I guess that’s what I’m saying, I think this should state that as a goal.

Paul Andersen: Would you be supportive if that change was made?

Robert Duncan: Yes, I would, because I think it would be important for someone that’s ARIN‑based and an ARIN-only member and has a little bit of activity in rest of world to be able to do that, without having to go and register with some other RIR.

Paul Andersen: But not willing to support as written then?

Robert Duncan: I wouldn’t state that.

Paul Andersen: Okay. Did you want to address his question or take it as feedback? Okay. Thank you for the feedback.

Anyone else who would like to speak on this? And I’ll speak slowly so that hopefully the webcast will come back up.

I don’t suspect ‑‑ did we have any remote participants before we cut them off?

Kevin Blumberg: We have some, but no questions.

Paul Andersen: Some comments?

Kevin Blumberg: The last comment was asking to summarize Mr. Howard’s remarks that were during the audio off. But we’ve got the transcript.

Unidentified Person: The audio is back up on the webcast.

Paul Andersen: Audio is back up. Thank you for that.

So this is the last call for comments. We’ll just give a few extra seconds in case the remote participants would like to ask any questions or queries.

But, again, we’ll close the microphones a few seconds. David wanted to make a quick comment himself.

David Farmer: If there’s anybody out there that deals with multiple RIRs and has any comment on this, it would be helpful. Thanks.

Paul Andersen: Which leads me to my next point, if you had comments that you didn’t want to make here, or questions or anything that comes up, please feel to approach the AC either at the meeting in the next day or two or drop a line on the PPML Mailing List.

But going last call for microphones at least in the room. Going once, twice. Closed. And just give a few extras. Anyone typing online? I think we’ll close that discussion. The feedback has been received by the AC.

[Applause]

Recommended Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate

John Curran: Okay. I want to move right along. Now we’ll talk about the next policy, which is Recommended Draft Policy 2014‑17, Change Utilization Requirements From Last Allocation To Total Aggregate.

History of this: This started as ARIN Policy Proposal 209 in May 2014. The AC shepherds: Andrew Dul and Owen DeLong.

It was presented at the PPC at NANOG 61 and 62. It was presented at ARIN 34.

[Audio difficulties]

David Huberman: If they need to get more space because it’s fragmented or they have immediate needs for more than a /24.

But at the same time, if you had a single /20 from ARIN instead of four sequential /22s, you would be at 80 percent with this type of usage. And so you’d be eligible to receive additional address space. So there’s a little bit of mathematical inequity there.

So the policy asks us to replace the existing section as John described, remove the 80 percent and put in 80 percent overall, 50 percent on each individual allocation.

Since the last time we discussed this we added the 50 percent overall to mitigate the staff and legal concerns regarding the possibility that a large provider could simply get a new block immediately after receiving another new block, because they’re well utilized on their other space.

What you need to know is the ARIN AC is ready to move this to last call. We’re ready to make this policy.

If you do not support this policy, you really need to speak up now and tell us why. Otherwise, if you have statements of support, we’d also love to hear those. Thank you.

Paul Andersen: For those new to our consultations, it is not necessary by the Policy PDP for us to take this to another ARIN PPM.

So it’s important that if you anything on this, that you approach the microphones. I understand we’re still having some remote participation issues. So our apologies to that.

Last call for those that would like to comment. Support or not support. Please don’t all rush at once. Do we know if we’re getting any remote participation.

Kevin Blumberg: There’s no audio right now.

Paul Andersen: There is no audio. Perhaps you could summarize what’s been presented. I’ll ask for a show of hands. This is your opportunity to make any comment. Otherwise, I’m going to close the microphones.

I’ll ask if our pollers are armed and ready. Thank you as always. So this is an opportunity for audience participation. A good chance to stretch early in the morning.

Question first asking those who are in favor that the AC move this Policy Proposal to last call and I’ll ask for those who are opposed. I ask that you keep your hands high.

And I just ask a question ‑‑ and I’m going to pause for a second only on this one. Is there any remote participation?

John Curran: They’re telling them remotely.

Paul Andersen: I’ll wait for a few seconds before the poll so they can be typed to so they understand what’s going on. If that’s acceptable. So talk amongst yourselves for a second.

This is when we see how Kevin Blumberg’s keyboarding from grade seven worked out for him.

Kevin Blumberg: It’s good.

Paul Andersen: Okay. All those in favor of the question, please raise your hand, nice and high, and please keep it until asked to lower it.

There we go. Thank you. You can lower. And now those that are opposed, please raise your hands nice and high.

Thank you. One second for the tabulation. It may take an extra moment due to online difficulties.

On the matter of 2014‑17, those in favor of advance, 24; against, 0. Total number of people in the room, including meeting room and remote, 57.

This input is being immediately passed on to the AC for their consideration. Thank you.

Recommended Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization

John Curran: Very good. We’re going to move on to the next policy proposal. Looking for an update: Remote audio? Still no audio? Kevin, do they have audio?

Kevin Blumberg: Just came back.

John Curran: Just came back. Okay. Very good. I feel much better.

Final recommended Draft Policy is 2014‑19, New MDN Allocation Based on Past Utilization.

Originated as Policy Proposal 211 from August 2014. The shepherds are Cathy Aronson and Andrew Dul. It was presented at ARIN 32. Sorry, at NANOG 62 and at ARIN 34.

It advanced to Recommended Draft Policy in December. It’s online and in your Discussion Guide.

The policy proposes to change NRPM 4.5: Multiple Discrete Networks, bullet 7, to add additional qualifying criteria.

Currently sites applying under MDN will qualify for minimum allocation specified in policy or under immediate need.

This policy adds the option for new MDNs, new multiple discrete networks, with at least a year’s worth of historical utilization, to request up to a three‑month supply of addresses.

So presently there’s only two options. You either get the minimum, which in our policy is /24, or you have to show immediate need, which is usage of the address space within 30 days.

This says if you have a historical run rate and you can demonstrate the historical run rate, then you can request a three‑month supply using that historical run rate.

If implemented, staff would require the organization to show direct correlation between the demonstrated one‑year utilization and the discrete network three‑month need.

The policy requires an applicable one‑year utilization in order to qualify. This means that it would need to be ‑‑ you can’t give us a random utilization rate. It has to be for the area that you’re servicing with the MDN.

Does not create any legal issues. It would have minimum resource impact. It’s estimated that the implementation would occur within three months after ratification by the Board of Trustees. We need to update internal guidelines and staff training.

I’ll now turn it over to the AC to give policy proposal presentation 2014‑19, Cathy Aronson.

Cathy Aronson: Hi. I’m at the microphone again. Super exciting. So how do we move this forward? John talked about the problem statement.

Yeah. So the issue, the reason this came about is because an organization, some folks in the community felt that an organization should be able to be able to get more than the minimum for a new discrete network.

And the thing that we found out in the process of working on this proposal is it’s really not a change from what ARIN actually does in practice, because if you have a one‑year utilization rate, then it’s not a new multiple discrete network. If you can show it’s not actually a new one or it’s in the same market as an old one, you can actually use the one‑year utilization to justify it.

So it turns out it’s somewhat of a no‑op as far as what ARIN does in practice. And if you really do have a new, brand new discrete network, you don’t have a historic run rate to use to justify the three‑month utilization. So you should actually get the minimum.

So the question ‑‑ anyway, this is the change in the policy text. John talked about all of that. So really the question that I want to ask of you all is whether you feel that this is a useful clarification to the policy to have this text in there or we should just go back to leaving it for just new discrete networks, because it really doesn’t change what ARIN does in practice.

I think we have questions. Yeah. So that’s what we’re really looking for as the Advisory Council from folks. And maybe you could comment on that and/or ask questions if I’m not clear. Or just general crickets.

Paul Andersen: So we’ll open the microphones now. We’d love feedback on this. I’m just curious, just so I know, are we getting audio again?

That’s good. Please approach the microphones. This is a policy that is possibly being moved to last call. So ‑‑ any remote participation?

Perhaps the lack of feedback is it just goes to the stellar presentation, you’re just so clear. We really appreciate if you could come up and give any kind of feedback. Thank you, sir.

Lee Howard: If you’re going to beg. Lee Howard, Time Warner Cable. This seems, especially since it is congruent with current existing operational practice, I don’t see anything objectionable there.

I’m curious about, I don’t think the proposed text says this, but my only concern would be in terms of a gaming situation. I would assume ‑‑ I would hope that the new discrete network would be similar to previous discrete networks and not a completely new line of business being started up.

And John’s nodding. Good.

Cathy Aronson: I think the author of the proposal originally felt that if he had a discrete network and he split it into two. And he assumed that if he did that, those would be new discrete networks. But in ARIN’s eyes those are actually existing discrete networks and they have a track record.

So he wrote the policy in order to try to help this situation where he split one in half and it turns out that all the right things would happen if he did that.

Lee Howard: That makes sense to me. My use cases were a regional ISP adds a new region or a datacenter or a cloud hosting company opens a new datacenter, those would be analogous lines of business.

But if a content company went into the Internet provisioning business, that would be a completely new line of business and previous usage wouldn’t be analogous. That’s pretty obvious.

Paul Andersen: John wanted to get in first.

John Curran: Presently those are handled by assigning the minimum or they demonstrate their entry into that new business and they use the immediate need policy.

We wouldn’t accept a non-synonymous business history for predicting an entirely unrelated business.

Paul Andersen: Okay. Last call for questions, either remote or in person. Please approach the microphone with due speed if you’d like to comment.

Seeing none, we’ll close the microphones. And it’s been requested that we take a poll of the room on this.

Again, as a reminder, there’s a desire to take this to last call after this Public Policy Consultation. So similar to last one, I will ask for a poll of the room. First those who are in favor of the AC moving it to last call and those who are opposed.

So I’d ask all those in the room who are in favor to raise your hand, nice and high. This is our last recommended Draft Policy of the day. So please keep it up. Got it. Now you may lower it. Thank you.

Now those who are opposed, please raise your hand, nice and high. Okay. One moment for the results, as we also poll the online audience.

Thank you, sir. On the matter of 2014‑19, on the question to advance: Ten in favor; two against. Total number of people in the room still and online still 59. This will be passed to the AC for their consideration. Thank you very much.

Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text

John Curran: Moving right ahead. We are doing very well for time. We’re going to fit in discussion of Draft Policy 2014‑6, which is not a recommended draft. It’s just a Draft Policy. So I’m going to have the AC just present their status on it. Go ahead.

Kevin Blumberg: Good morning, everybody. So we’re going to be discussing ARIN 2014‑6: Remove Operational Reverse DNS Text. We have changed this from remove Section 7.1. We don’t have the screen. John. Do I have to do anything on here?

John Curran: There we go.

Kevin Blumberg: So at the last meeting in Baltimore, a lot of the discussion was centered around the fact that we were removing Section 7.1, which was v4 policy, where we also had this in v6. And it was kind of ‑‑ I think silly is the wrong word, but if we’re going to remove an operational need for v4 when it comes to IN.ARPA, may be doing it for v6 at the same time, getting the community’s feedback at the same time would be more appropriate.

So we’ve changed the title of this and included the fact that we will be taking out both 7.1 and 6.5.6. So why is there an issue?

We have a policy in ‑‑ we have a draft here that is basically looking at the fact that we have text in the NRPM that requires Internet service providers to put in address, in ARPA addresses for all of their customers. This is operational.

It’s not necessarily enforceable. It doesn’t say what the enforcement is. There’s a number of issues. And the question is: Has it really been used?

If we’re going to look at the new people coming in to the community and looking at our glorious NRPM text, will this confuse them, cause concern, or is there something that we need to include at this point, is it something complicated that we need to include?

It’s not based on any RFC, and right now it’s really just an operational practice.

So the author has asserted this should just be taken out of the NRPM. And the policy statement is incredibly complicated. It’s just completely strike 7.1 and 6.5.6.

So it’s predominantly a cleanup policy. Like I said, it was at the last meeting in Baltimore. Since then we’ve added in those two changes.

And I’d love some feedback from the community, especially operators at the community, at the table here. If you have any feedback from Baltimore, since the change, or if you are new to this discussion, do you have any input in this policy?

Paul Andersen: If I have to approach a microphone, you guys have to. Come on. Rear microphone, sir.

Michael Sinatra: Michael Sinatra, ESnet.

Paul Andersen: It’s hard hearing up here.

Michael Sinatra: Michael Sinatra from ESnet, the Energy Sciences Network of the US Department of Energy. I support the policy. I support getting rid of these two pieces.

I especially was amused in looking at Section 6.5.6, when making address assignment, the organization must delegate to an assignee organization upon request the responsibility to manage their reverse lookup zone. It corresponds to the assigned address.

This is not only specifying operational practices, actually specifying the business model of what service you provide and how you provide it.

So I actually think that does not belong in the NRPM and I support the policy.

Paul Andersen: And you do not support the policy. Any question or feedback?

Michael Sinatra: I don’t support these things being in here. I support the proposal.

Paul Andersen: The proposal but not ‑‑ I do apologize, that rear microphone I’m having a hard time hearing.

Front microphone.

Lee Howard: Lee Howard, Time Warner Cable. And author of draft-howard-IPv6rdns, talking about how we do reverse DNS in IPv6.

Basically saying that you don’t. Or that’s one recommendation is that for a residential ISP providing PTRs is meaningless, because they don’t provide any information and you can’t prepopulate a reverse zone in v6 the way you can in v4.

Sorry, I rambled a little bit. Read the draft. So what I missed here and I didn’t have time to read right now is this ARIN delegating responsibility for reverse, with the addresses, or is this the organization receiving the delegation for the delegating to its parties?

John Curran: Repeat that slowly.

Lee Howard: Does this proposal affect ARIN’s delegation of reverse to ARIN members or ARIN delegatees, or does this affect the ISPs who receive addresses being required to delegate to their ‑‑

John Curran: This doesn’t change ARIN’s services at all. We’ll continue to provide the same services, same delegation. This just removes a statement of an implied obligation in the policy text on our customers. We don’t change the services; we’ll still delegate.

Lee Howard: ARIN still delegates. Because I remember there being a policy discussed many years ago about lame delegations, that ARIN delegates to the member or the organization. And that if that server to which the delegate is lame, then ARIN can remove that delegation, which would be a good idea because lameness is bad.

I just want to make sure that we’re leaving that intact.

John Curran: This doesn’t change the services we provide. Note that lame delegation testing and removal is a separate topic.

Lee Howard: That’s what I wanted to know. So on that basis I have no problem removing this.

Paul Andersen: Support. Any remote participation, David?

David Farmer: Nothing there.

Paul Andersen: Last call for the microphone. Front microphone.

David Huberman: David Huberman from Microsoft. I’m the author of the Policy Proposal. The reason I proposed it ‑‑ I’ve said a few times now ‑‑ there’s some important DNS rules that the RIRs have enacted with respect to reverse. Rules in v4, for example, that if you were the registrant of a whole unit of a /16, that ARIN and the other RIRs will only delegate the /16 as essentially ARIN zone in the IN‑ADDR.ARPA tree and you, therefore, as the registrant responsible for individual sub zones /24s typically. There are similar rules in IPv6.

These rules are very important. They should be well known. I’ve asked ARIN a few times to please participate in the RFC series to make this an RFC as it’s an important operational practice of the RIRs.

But it doesn’t belong in the NRPM which in my opinion should say: Do you get resources, how do you qualify, yes or no?

And it’s not about operational practice or much less, as Mr. Sinatra notes, business policy.

Paul Andersen: Rear microphone.

Nicole Black: Nicole Black, SoftLayer Technologies. So I’m kind of new to this issue and I’m sure it’s probably been thought over. But also I do agree these should go. They’re kind of oddly shimmed in there and weird.

But are there any possible negatives that have been considered for, if people don’t feel compelled, because it’s written in here, to properly maintain our DNS?

Paul Andersen: I’m sorry, I’m having ‑‑ would you mind coming to this microphone at the front. I apologize. We seem to be able to hear you, not just you, obviously, but the previous speakers, too.

John Curran: Apologies for that. Repeat one more time.

Paul Andersen: Maybe knock that and bend it down. Thank you.

Nicole Black: So basically to boil down to all of that is: Are there any possible negative consequences for people ‑‑ you said this probably hasn’t been enforced anywhere. But if people don’t feel compelled because it’s written down to properly maintain these, is ‑‑

John Curran: I believe you’re asking: Does making this change have the potential for negative consequences?

And so this will be a very, an interesting statement in humility for ARIN.

I’m not sure the presence of the current language in NRPM meaningfully affects the behavior of anyone. So its removal probably also won’t meaningfully affect the behavior of anyone.

In fact, if it was believed that the statement there actually made a significant impact, then there might be a different approach, but I think as people have indicated it’s the wrong place for this type of statement. It really is the type of operational practice that operators should be talking about at their forum.

Paul Andersen: Thank you. Thank you for your comment. Michael, if you don’t mind, I apologize.

Michael Sinatra: Michael Sinatra, ESnet. I wanted to clarify my position also. It’s the same as John’s.

This should be written down somewhere, as part of the BCOP process, the RFC process, but it shouldn’t be in NRPM. That’s really what we’re saying, I think that’s what David’s point is also.

Paul Andersen: Thank you for the clarification.

Front microphone.

Joe Provo: Joe Provo, Google. Echoing Michael and echoing David: Yes, yes, yes, not in the NRPM. Thank you very much. Support support support.

And echoing David about maybe ARIN’s participation in the RFC process for the v4 elements, if they’re of interest to continue pursuit and recommend the practice.

Paul Andersen: Thank you for that comment.

Last call for comments and then look for any online. David? No online. So thank you.

That was good to get a little bit of vigor going there. So thank you for your feedback.

Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers Recommended

John Curran: Okay. We’re actually doing very well for time. We’re going to move promptly ahead.

Next up is a discussion of Draft Policy 2014‑21, which is Modification of the CI Pool Size Per Section 4.4. I’m sorry. Draft 14‑14, Removing Needs Test for Small IPv4 Transfers.

And I have Dan Alexander.

Dan Alexander: For this one, the shepherds weren’t available for the presentation. And it’s really just ‑‑ they just wanted to provide kind of an update on the discussion because what this proposal is proposing ‑‑ that’s redundant ‑‑ is basically for smaller transfers that the needs test that staff would perform would be removed.

There’s been a lot of conversation on the Mailing Lists and at different meetings, and there’s a fair amount of disagreement as to where that demarcation would be placed, whether it’s a /16 that’s in the original text or whether it should be lower and possibly move that threshold up progressively as we got better feedback or experience from what the impacts might be. There’s also a fair amount of discussion around the premise of the proposal.

Because originally the problem statement of the proposal suggested that there was too much of a delay in staff processing for these transfers because of this needs test.

And in reality, the needs review is actually a smaller portion of the time that the staff spends on these requests, because more of the time is actually spent verifying the requester and who they are.

And also since then the queue of work that ARIN staff has been working on ‑‑ they’ve reduced that queue back to normal kind of wait times for requests.

So the shepherds are really looking at possibly either a complete rewrite of this or really reviewing the problem statement as to whether this is necessary.

But we’re definitely open for feedback here. But they wanted to let you know that a rewrite of this is likely coming, but definitely always looking for our input.

Be very curious if people think this is a good idea and if so do they like this kind of threshold. Do we want to go down this path? So input is always welcome.

Any thoughts, questions about the proposal?

John Curran: Any comments? Seeing no comments, we’ll move on to the next policy. Okay.

Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 Recommended

John Curran: Next up is Draft Policy 2014‑21, Modification of CI Pool Size Per Section 4.4. This is also a Draft Policy.

And it is as such ‑‑ I’m just going to have the shepherd come up and speak to it, and we have Dave Farmer right by me doing it.

David Farmer: So problem statement: We’re seeing some growth in IXPs due to some efforts by this community. This is a good thing.

There’s currently a /16 that’s been reserved. And this is looking to expand that. Changes the reservation from a /16 to a /15, adding an additional /16.

There’s only been the 35 /24s of the 256 in the current /16. That’s less than a 14 percent utilization of that.

There will be additional resources coming in March 1st and September from, one, from the IANA pool. In both cases this should be well over a /16. So even if the free pool exhausts prior to implementation of this policy, there will be resources available to implement it in theory.

Policy statement is pretty clear. Simple. In the full text you’ll see the text that’s being removed, the full text in the discussion guides and it’s basically changing that to a /15. So discussion: Is the additional /16 needed and justified? I want to make sure everybody realize we only used 35 of the current ones.

So we’re adding an additional 256 /24 equivalents. So this is putting aside a chunk. But again, in the total scheme of things, a /16 isn’t that much.

There’s been moderate support on PPML. No opposition. Based on feedback, we’ll probably take this to last call, or not last call, to recommended draft status prior to ARIN 35.

Paul Andersen: Now would be a great opportunity to get wording or other changes so that hopefully when it gets to San Francisco, it will be in a policy form. Front microphone.

Martin Hannigan: Can you back up to the first slide?

Paul Andersen: Can we get your name and affiliation.

Martin Hannigan: Martin Hannigan.

Paul Andersen: That one?

Martin Hannigan: No, that one. Out of the 35 /24s used, how many were used in 2014 previously?

David Farmer: This is, I believe, Leslie. I believe that’s the 35 since the /16 was reserved. 2013 and 2014.

Martin Hannigan: But how many of the 35 were issued in 2014? Most of them?

John Curran: We have to get a breakdown.

Martin Hannigan: On the next point, additional resources will come from the IANA recovered ‑‑ blah, blah, blah. I’m not sure what that has to do with this.

With respect to the pool, doesn’t this pool share with other critical infrastructure? It’s not just IXPs, it’s gTLD and whatnot?

John Curran: Critical infrastructure of all types.

Martin Hannigan: And how much of the address space has been claimed by the gTLDs?

John Curran: How many of the CI allocations? I don’t think we’ve had a gTLD come through. I don’t recall one.

Martin Hannigan: I think the first wave ICANN gTLD approvals was on the order of 900 and the next wave is going to kick in.

Paul Andersen: The current round?

Martin Hannigan: The current round was 900 approved.

John Curran: Over 900. And they’ve been out, operational for over a year now.

Martin Hannigan: Slowly releasing them into the DNS. And the next window for new gTLD applications opens, I think, in another six to 12 months.

Paul Andersen: I don’t think they’ve announced a second round.

Martin Hannigan: Intention was three years, if I remember correctly. So obviously I support the policy as written.

Also, I know that while Dave Temkin is not here, the Open Access Association, standards body with respect to interconnection, supports this policy as well as written.

I believe that there was some discussion on the ARIN list related to this. You can take that or leave it. But there is support from others including trade associations.

Not sure where you want to go with this, Dave. But I think there’s more than adequate support to move this forward.

And I think that the pool size, at least the utilization, right now is a red herring with respect to the nonperformance of the gTLDs. Perhaps the better way to go, if you don’t want to increase it from a /16 to a /15, is just remove the access of the gTLDs and dedicate it to critical infrastructure that is claiming it.

Paul Andersen: Can I get clarification. I know you mentioned the OIX. That was based on consensus from the Mailing List they have?

Martin Hannigan: Board adopted policy ‑‑ we don’t write number policy, so ‑‑

Paul Andersen: Understood. Did you have a question for ‑‑

Kevin Blumberg: I have a clarification.

Paul Andersen: One second so we can just ‑‑ you want a response ‑‑

David Farmer: Marty, these points aren’t trying to argue against it. It’s mostly making sure full disclosure, making sure that everybody realizes where we’re at.

Martin Hannigan: Understood. They just weren’t clear enough. Thank you.

Paul Andersen: Thank you for your comments and support.

Kevin Blumberg: Marty ‑‑ is this remote or ‑‑ no, this is me, something specific.

gTLDs are excluded from this specific pool. And the last part of Section 4.4, this was added in a while back, was ICANN sanctioned gTLD operators may specify up to a /23 from the free pool or transfer but not from the above reservation.

So gTLD operators are actually excluded from the ‑‑

Martin Hannigan: But the pool is shared, if I remember correctly. And I don’t have a guide.

Kevin Blumberg: I’m reading from the NRPM specifically.

Martin Hannigan: Not shared with anything. I’m talking to them. So it’s not shared with anything at all?

Kevin Blumberg: No, there are other critical infrastructure. But the specific concern about gTLD is in the numbers ‑‑

Martin Hannigan: But it is shared?

Kevin Blumberg: Correct.

Martin Hannigan: That’s my point. Thank you.

Paul Andersen: Other comments? Front microphone when you’re ready.

Lee Howard: Lee Howard, Time Warner Cable. I disagree that a /16 are negligible. There are lots of people who need /16s and smaller. And reserving another one, there just aren’t that many left.

The next IANA allocations I believe is a /13, and then a /14. And they’re getting smaller and smaller. So that’s a significant chunk of that.

And from reading that second bullet, I haven’t seen a demonstration that this is needed. 14 percent is used in a year and a half. Yeah, sorry, that looks like there’s enough to last for another seven years, at which point v4 is dead.

So I oppose.

Paul Andersen: Understood. Thank you.

Approach the microphone. I see ‑‑ go ahead, sir.

Martin Hannigan: Martin Hannigan. But Lee’s wrong. It’s not 35 percent in two years. It’s actually the majority of this last year, and if it doesn’t get used, rewrite the policy in a year or two and take back a /16.

I think that you’ll find that the growth rate probably maps out reasonably to three years to some significant amount of utilization. In the last four months alone, I think we saw seven new IXPs come on the radar and significant growth in others. There’s a major expansion happening in the San Francisco Bay area with one.

There’s another that ‑‑ there’s a few announcing in Chicago. So I think the ramp rate is probably reasonable. But if it turns out to be a dud, take it back. Take it back in a year. Take it back in a year and a half if it doesn’t map out.

But I think, and don’t forget, the pool is shared. And perhaps the rewrite, if we don’t, again what I said earlier was, if we don’t want to increase it to a /15, then remove the other users from the pool and make access to it smaller. That’s a reasonable compromise, in my opinion.

Paul Andersen: Martin ‑‑

Dan Alexander: Just a question, because one of the things that came up in the discussion, kept saying that that if you didn’t need it, we could take it back. But we are going to run into a scenario where the free pool will deplete, so we’re looking at, in setting this /16 aside, you’re going to have possibly a dozen or X number of possibly small providers who are going to hit the wall sooner than if this /16 were available in that free pool, versus the possibility for some IXs that may come down the line maybe two years from now.

So we’re just wanting that, if we were to do this, everyone understand that there are smaller providers who may not get that last dip at the well.

Martin Hannigan: These are small, typically small IXPs that want to get a dip at the well as well and they’re aggregating those same small providers. I think that you’ll also see some benefit with respect to aggregation. That’s kind of a red herring, actually. But at the end of the day, everybody is small and wants a piece of the pie.

I think there’s multiple reservations we could pick away at and debate if they’re necessary or not. I believe this is the smallest one out of the reservations that we have.

And perhaps we go look at the, I don’t know, what are the other pools we could go look there and we could take a /16 and move one from the other, and I guess there’s technically no impact on the existing free pool.

As well there’s a /11 coming from the IANA that will extend the life of the existing free pool significantly. So I really don’t think that this is that big of a deal.

If it is, let’s revisit it in a year and a half or two and rewrite it and I think that you’ll have less agreement or more agreement if it’s 70 /24s out of a /16 and we go out of a /15 and we go back and take a /16 away, I don’t think you’ll have any opposition at all.

But I think that there’s a lot of ‑‑ again, if you look at the ramp rate, if you look at the potential, I think critical infrastructure has always been distinguished with respect to the Internet.

I don’t think there’s any argument that TLDs and IXPs are critical infrastructure. Again, if you’re concerned that it’s too big remove the TLDs from the policy and leave the IXPs in. That’s the compromise, in my opinion.

Paul Andersen: Thank you for your comment and support.

Cathy Aronson: Cathy Aronson. I have a question for people in the room. Seems to me that maybe some of the current IXP providers are actually getting their /24s from the free pool and not from this pool.

And I just wondered if when we run out maybe the take-up rate for this allocation is going to get bigger because of that. And we should consider that.

Paul Andersen: That would be a good thing to dig into for our ‑‑

John Curran: We can look to see ‑‑ recognize that we don’t have a lot of people coming to us specifically as a new gTLD provider looking for address space.

Cathy Aronson: I’m talking about ‑‑ gTLDs aren’t included in this. I’m just talking about like exchange providers, are they getting, currently getting blocks from a block they already have or from the free pool, not from this critical ‑‑

John Curran: I see. Are there providers making ‑‑ if you’re an exchange provider and you’re already associated with an ISP or hosting company, you’re often taking a block and just utilizing that.

Cathy Aronson: Right. So when we run out, the free pool runs out and those service providers don’t have blocks anymore, the take-up rate for this like for exchange points might grow more than it has.

John Curran: Quite possibly. It is true that we are seeing a lot of exchange point activity. And there may be even more we’re not seeing, which is presently being satisfied by existing allocation policy.

Paul Andersen: Thank you. Does that address your question, or did you want us to potentially seek for San Francisco, seek that data if it’s findable?

Cathy Aronson: I thought since we’re in an audience of Internet service providers that somebody might be able to speak to that, like I’m an exchange point operator and I get my /24s through an exchange point from my current whatever. I just thought that ‑‑

Paul Andersen: That would be great feedback. Encourage that.

Anyone else wish to make a comment, Kevin? David would like to make a comment.

David Farmer: I’ll just say that it is from personal experience on an exchange, we started up in somebody’s block. And then once we proved that we can actually get the exchange going, then we went to ARIN.

Because nobody wanted to fill out the paperwork if it was going to fall on its face.

So there’s some precedent for what you’re talking about. That does occur.

Paul Andersen: So there’s no further comments. I think we will close this off. And I think we have room for one more? For a break? Thank you for the feedback on that.

John Curran: Thank you. It has occurred to us that we have a break coming at 11:00. But there’s 14 minutes and we only have one Draft Policy left.

So we may actually be able to finish prior to break, which would be wonderful in many ways.

We’ve lost the cursor. It’s on the screen. Thank you. It’s on the screen. You can’t see it. The other screen.

Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10

John Curran: Okay. Next policy, Draft Policy ARIN 2014‑22, Removal of Minimum in Section 4.10.

This is just a Draft Policy. I’ll turn it over to the AC to present. And I see Kevin’s behind me. Let me get this up.

Kevin Blumberg: This is ARIN 2014‑22, Removal of Minimum in Section 4.10.

So effectively the problem statement is 4.10 is for getting small blocks of IPv4 for your IPv6 deployments.

It’s a /10 pool that is available to ARIN customers when there’s nothing left in the free pool. This is the last little sort of reserved special use block for kickstarting your critical infrastructure as an example.

So the problem statement is basically the minimum allocation and assignment in this section is a /28. And from an operational standpoint that’s an unroutable block.

There’s been some very recent studies showing a /28 is 10 percent routable at best. /25 might be 15 percent. It’s gotten worse, not better, actually, over time.

So this would change the policy from the /28 to what has sort of, in the NRPM, become sort of the de facto minimum, which is /24.

And it basically sets out that that is what it will be. So there’s the text. Keep it very simple. Okay. And there’s ‑‑ sorry, it was only 13 percent for the /25.

PPML discussion: No advantage. ISPs will react quickly to allow longer prefixes. We’ve got a bunch of ISPs, I’m hoping, in this room. I’d love to hear if there’s a specific block that is assigned. There is a specific block, a /10, would you open up your prefix filter as an example to allow /28s to flow through on that specific /10. Is that reliable and is that something that we can expect to see quickly?

And this block is intended for a lifeline. That lifeline ideally would not be attached to an anchor. Basically talking about the routability. Next step. So we’re requesting feedback. Do you agree with the problem statement? Do we need to change the allocation size?

And are you concerned about reachability of these prefixes?

Paul Andersen: Our last opportunity of the day to give some feedback. Please approach the microphone with your feedback for the AC on this. Front microphone, please.

Donny Roisman: Donny Roisman with SoftLayer. Can you go back the policy language? Was only up for just a second. There we go. All righty.

So I fully support this change and I do agree that the minimum allocation should be a /24 because the reality on the Internet is that a /28 is not of much value.

Paul Andersen: Thank you for that support. Go ahead, sir.

Lee Howard: Lee Howard, Time Warner Cable. The proposed language says this block will be subject to an allocation of /24, does not say to a minimum of a /24. That means you get a /24, done? Nothing larger? Whereas the current policy says maximum size of /24.

Kevin Blumberg: Right. So further down in the policy it says you can only get an allocation from this reserved pool every X.

So, yes, it would be ‑‑ in my reading of it, that would be the case.

Lee Howard: So I do believe that the reason we designated a /10 for this purpose is specifically we said this /10 was so that filters would be updated.

However, I’m trying to do the math in my head of how many /24s there are in a /10 and it’s quite a few. It’s probably as many as there would be organizations who need transition technologies and therefore this is probably effectively harmless and it simplifies things. So I would support it.

Paul Andersen: Support. Okay. Thank you. Next one. Please.

Mike Sinatra: Mike Sinatra, ESnet, I also support it. The notion that ISPs may eventually change their policies in order to allow /28s is if it does happen, it’s not going to happen in the timeframe this block is actually necessary for people to use. So I actually think that it’s very necessary to make this policy change and I support it.

Paul Andersen: You support. Remote participant.

David Farmer: Two comments here. Andrew Dul, ARIN AC. One thing we must note is that if we change the minimum, I think it would be from a /28, we greatly reduce the number of possible organizations that can benefit from this policy.

Second one is Gary Buhrmaster: Speaking for myself, this proposal appears to presume that ISPs will not update their filters. To help me understand whether I need to support this proposal, can I request a straw poll hands up of those in the room asking how many ORGs there are or will be updating their filters to allow a /28 from the assigned /10 prefix and how many will not be updating their filters.

Paul Andersen: Instead of a straw poll, perhaps that might be a useful question to take to the PPML from the shepherds so we get a wider sample.

David Farmer: Sounds reasonable to me. I was just reading.

Paul Andersen: Hopefully he’s hearing me through the audio cast. So I think that would be the best. And did you want to respond to the other one?

Kevin Blumberg: Actually I just wanted to respond to that. One of the aspects of 4.10 is for critical infrastructure.

So one of the issues is some of the people doing there or most of the people doing the /28 filters, is that good enough when it’s for critical infrastructure? So just a comment on that.

Paul Andersen: Thank you. Please approach the mics. We’ll be closing them soon. Front microphone.

Joe Provo: Joe Provo, Google. Support as written for all the pragmatic reasons as already been pointed out. At one point in time it may have been of interest to expand v4 life and I hope a lot of people would update their filters. But v6 is so functional, now that’s a silly thought.

Paul Andersen: Okay. Last chance. Please approach a mic if you wish to comment. Otherwise we’ll close the mics. Once. Twice. If you don’t stand up now.

The microphones are closed and remote if there are, please finish off. Last comment to you in the room.

Michael Sinatra: Michael Sinatra, ESnet. Once again, ARIN policy should not be dictating operational practice. Even if ISPs are required to change their filtering policy, which imposes costs on them because it means they have to carry a larger routing table, it may not be that much larger if they only accept /28s from this block but it’s still larger.

ARIN policy should not be dictating operational practice in this manner. So regardless of whether you think they’re going to do it or not, I think they’re not, but it shouldn’t be dictated by this policy.

Paul Andersen: Understood. Thank you, sir.

If there’s no more remote participation being typed, we’ll close it off and thank you to the shepherds for this.

And I’ll conclude and invite John for closing comments.

Closing Announcements and Adjournment

John Curran: Thank you, Paul. Thank you. Okay. That concludes our Policy Consultation. I’ll put the cursor from here to there. Get some new fresh slides up.

Thank you, everyone, for coming. We’re going to continue the discussion of these on the Public Policy Mailing List. And I will see you all at ARIN at the ARIN 35 meeting, 12th through the 15th of April in San Francisco.

Thank you everyone.

[End of meeting]