ARIN 43 Public Policy and Members Meeting
Day 1, Raw Transcript

Note: This text is the result of live transcription work conducted by professional 
transcriptionists for the purpose of creating an aid for participants in this ARIN meeting. 
It is currently unedited and has not been proof-read or corrected. It should not be relied 
upon for purposes of verbatim citation of the meeting proceedings. Although the 
transcription is largely accurate, in some cases it is incomplete or inaccurate due to 
inaudible statements made during the meeting or transcription errors. It is posted as an 
aid in understanding the proceedings at the meeting but should not be treated as an 
authoritative record. A clean and proofread transcript, that has been edited for accuracy to
match the audio/video recording of the meeting, will be published approximately one 
week following the close of an ARIN meeting as part of the formal meeting report.


BRIDGETOWN, BARBADOS, APRIL 8, 2019, 9:00 A.M. 
              -oOo-
              
PUBLIC POLICY MEETING, DAY 1 - OPENING ANNOUNCEMENTS
              John Curran:  Good morning.  If folks will come in and be
seated, we'll get started.  
              Welcome, everyone, to lovely Barbados.  I'm John Curran,
president and CEO of the American Registry for Internet Numbers.  I'd
like to welcome you to ARIN 43.  
              Here we go.  So I'd like to say we have a very busy
meeting, and we have quite a few folks here to help participate in the
discussions.  And I'd like to say that our Board of Trustees is here. 
So that's Dan Alexander, Paul Andersen, Nancy Carter, myself, Regenie
Fräser, Patrick Gilmore, Peter Harrison and Bill Sandiford.  We have our
chair, Paul Andersen, our vice chair, Bill Sandiford, up here at the
table.  
              Our Advisory Council is here.  There's 15 of them.  I
won't read the names.  AC members, please raise your hand.  That's the
ARIN Advisory Council, and they work on shepherding the policy process. 
When you folks propose ideas, the ARIN AC is responsible for taking
control of those, moderating the discussion on the list, updating the
proposal and coming up with fine ideas for us to discuss here in this
room.  
              The chair, Tina Morris, is here, at the head table.  And
Leif Sawyer, the vice chair, is also at the head table.  
              We have a number of folks from the NRO Number Council --
Kevin Blumberg, Louie Lee and Jason -- well, Jason isn't here.  But
Kevin and Louie are here.  
              The NRO Number Council is the organization that works on
global policy.  They get together with the other representatives from
the other four RIRs, and together they work out the global policies used
to administer the central pools at the IANA.  The central pool of IPv4,
IPv6 and ASNs are administered by the policies those folks work.  
              Those policies are actually developed here and harmonized
by this group until they're consistent in all five regions, then they're
ratified and used.  Haven't had a global policy in quite some time,
which you might say is a good thing.  
              Our RIR colleagues.  The RIR system has five RIRs.  We
have folks from AFRINIC, APNIC, LACNIC and RIPE here, making sure that
they can bring back to their communities what's going on in ARIN
because, while we all have our own portion of the registry, it is one
total global registry.  And so to that extent, we need to coordinate.  
              We have our ARIN leadership team here.  This is the senior
management team of ARIN:  Myself; Richard Jimmerson, our COO -- Richard,
where are you hiding? -- Anne-Rachel, who handles our government
affairs; Aaron, who handles our HR and admin.  
              Susan Hamlin here in the front row -- Susan is the one who
makes this meeting work, her and her team -- senior director
communications and member services.  
              Mark Kosters, who runs our engineering; Leslie Nobile, who
handles global registry knowledge, tracking what's happening across the
integrity of the whole registry; John Sweeting, the man who runs the
registration services, probably the department most of you interact
with; Val, who handles our financial services, hopefully the department
you don't have to interact with much because everything is smooth;
Michael Abejuela, our associate general counsel; and Bevil Wooding, our
Caribbean outreach liaison.  
              We also have Steve Ryan, our general counsel, here in the
back.  Very good.  
              We have our ARIN Fellowship Program, and the Fellowship
Program provides for people to come to ARIN and be able to learn what
we're doing here and bring it back to their communities.  
              This year we have three Fellows from Canada.  You can find
them because their badges prominently have a Fellowship.  So you have
Jaymon Lefebvre, Imran Mohiuddin and Matthew Wilder, are our three
fellows, and they have mentors from the AC. 
              And the Caribbean -- we have a lot of Caribbean Fellows. 
That's wonderful.  So Suzette Burley, Rudolph Daniel, Krislin
Goulbourne-Harry, Richard Hamilton and Cathrona Samuel.  If I've maimed
your name, I'm sorry; find me at the break, and I'll get it right on the
future slides.  
              And U.S., we have four Fellows from the U.S. area --
Jeffrey Anderson, Mike Arbrouet, Frank Hoonhout and Barry Sherwood. 
These folks are here.  They're attending and learning about our policies
and processes, and then they're going back to their communities so
people understand in their communities in their part of the world what
we do here at ARIN.  
              So all of our newcomers attended an orientation yesterday.
 They get to meet the staff, our representatives from AC and Board, and
they learned about ARIN.  
              So we have them fill out a survey that talks about what
went well, what doesn't go well, what additional information we could
add to the newcomer orientation.  
              At this time I'm going to do a drawing of those surveys to
give out a gift certificate.  We like to encourage participation.  I
need someone from the audience, second row, third one.  Owen, come on
up.  
              (Laughter.) 
              It does appear random.  You sit in different places.  
              (Laughter.) 
              Thank you for filling out these surveys.  They're very
helpful to us.  
              And the newcomer who filled out this survey Michael
Casadevall.  You'll get a certificate -- you don't need to come up;
we'll email you a gift certificate for $100 from ThinkGeek.  Thank you
for filling out the survey.  
              We have remote participants as always.  The remote
participants have a webcast of this going on in the back.  They have a
live transcript of what we say, which is a good reminder that we need to
be polite to the transcription people and talk at something other than
my normal Boston pace.  
              So when you're speaking, speak clearly, slowly if you can,
because we want to make sure we have a good transcript.  The remote
participants often rely on that.  
              We have downloadable meeting materials.  They're on the
website.  They're also in your app.  If you have the app on your phone,
you can click, all get the meeting materials.  
              The virtual microphone and consensus polling via Slack. 
People who are remote participants, they have the ability to, when they
have a question, ask that online.  It will be read at the mic.  And when
we do a poll of consensus, a show of support, someone can add themselves
to that even though they're remote.  So you have full participation
remotely.  
              Attendance stats.  We have 63 attendees from the U.S.,
eight from Canada, 34 remote participants, 31 from the Caribbean and 15
from outside the region.  
              Emergency procedures.  Well, if there's an emergency, go
to the beach.  Head out the exit, find a nice spot.  Shouldn't have to
worry much about that.  
              Download the meeting app.  I mentioned this.  We have a
meeting app.  It's useful.  You can see the map of the hotel, where the
rooms are.  You can see all the sessions.  You can find out the
speakers.  You can find out the attendee list.  It's all available. 
Feel free to click on this link to get it.  
              I'd like to thank our sponsors.  Two of our sponsors, our
network sponsor, which makes sure we have connectivity and our webcast,
very important, C&W Business and Google.  Let's have a round of applause
for our sponsors.  
              (Applause.) 
              Additionally, we have meeting sponsors that make these
meetings possible because there's quite a few expenses and we don't
charge people for people who preregister for the meeting.  So our
platinum sponsor, Addrex, and our silver sponsor, IPv4Mall.  Let's have
a round of applause.  
              (Applause.) 
              Okay.  So a couple of things, the discussions of the
policies.  The Board of Trustees chair will moderate them, and they'll
make sure -- he'll make sure everyone can speak, has a chance to be
heard.  This means that please go up to the microphone and state your
name, affiliation, be clear about it.  
              There's rules in your Discussion Guide if you have a
printed copy.  Or you can go online or it's in, again, the online app. 
The guide says be polite, focus on the policy, not on the speaker.  
              Please speak once on a Draft Policy.  Give other people a
chance to speak before you approach the mic a second time.  
              You'll find all the guides online.  So we have a pretty
full agenda today.  Our agenda is we're going to have our sponsor, C&W,
come up, Jenson Sylvester.  That will be wonderful.  
              We have a Regional Policy Update where we talk about
what's happening in the five RIRs for address policy.  We have our AC
Docket Report.  The AC will talk about the draft policies and proposals
that they have to work on and what they're doing with them.  
              We have a Policy Implementation and Experience Report,
which is where we report back to the community issues we see with
policy -- how policies have been adopted in the past are being
implemented, any issues we might have.  
              We have the Internet Number Status Report, reporting on
the free pools maintained at IANA and the issuance out and how the RIRs
are all doing with their issuance of number resources.  
              We have a report from the IETF, from our IETF Reporter. 
IETF is the place that makes the protocol standards, changes the
protocol standards, adds new protocols.  It's always interesting to look
over the horizon see what's coming at us.  
              RDP, we have a consideration of two Recommended Draft
Policies.  Either of these could be sent to the Board for ratification
after this meeting.  
              The first one will be 2018-2: Clarification to Initial ISP
Allocation.  The second one will be 2017-12: POC Notification and
Validation Upon Reassignment or Reallocation.  
              In the afternoon we have consideration of Recommended
Draft Policy 2018-5: Disallow Third-Party Organization Record Creation. 

              We have consideration of a number of draft policies that
aren't recommended, which means they won't be sent to the Board
necessarily for adoption after this meeting, but could be recommended at
a future time, and they'll come back to this community for
consideration.  So that's ARIN-2018-6: Clarify Reassignment Requirements
in 4.2.3.7.1.  
              And we'll have a report of our website and routing
registry update.  We'll have consideration of Draft Policy 2019-1 on
IPv4 Request Requirements.  We'll have a Draft Policy update on -- for
2019-3, which is update on the IPv6 Deployment Block.  
              And we'll have a presentation from a study that was done
on economic factors affecting IPv6 deployment.  Should be an interesting
discussion.  
              We have then a presentation talking about future meeting
agendas.  So right now ARIN staff sets the meeting agendas, and we'd
like to talk to you a little bit how that's done maybe how you can help.
 
              And then we'll close for the day, and that will be our --
quite a Monday.  We'll be pretty busy today.  
              So there's a room out the doors and around the corner
called Garrison 1.  That's a policy discussion room.  If you want to
grab someone and talk about an idea and maybe make it into a draft
proposal or you want to follow up with a member of the AC, grab them, we
have a room set aside where you can discuss things like that.  
              Help desk.  Registration Services Department has a help
desk.  It's right outside the door.  It will be available for ARIN 43
and at CaribNOG which follows.  The hours are 8 AM to 5 PM each day.  If
you have an open issue, if you have something you're trying to do with
ARIN, a registration request that maybe is stuck or a ticket that's not
moving, come over and see the registration desk.  
              Women's Networking Reception tonight, 5 to 6 PM at
Needham's Ballroom 3.  
              We have a social tonight at Copacabana.  You're social
badge or regular badge will get you in.  We have shuttles running at
6:45, 7:00 and 7:15, and they start returning at 8:30.  This is a short
bus ride away for an authentic Barbados experience.  Should be a
wonderful time.  
              Okay.  After ARIN 43 this week we have CaribNOG meeting. 
And it will meet Wednesday through Friday.  And we have -- ARIN CTU has
a Public Policy group meeting taking place on Thursday.  
              So at the head table, I already introduced all these folks
so I don't need to do it again.  Thank you.  So we'll move right ahead
into the meeting.
              First one up is going to be we're going to bring our
sponsor presentation.  No presentation?  Very nice.  Okay.  Jenson
Sylvester, come on up.  
              Jenson is our sponsor of this meeting, C&W.  I don't have
a bio?  I know your bio.  Come on up.  Jenson has been involved in 15
years in telecommunications at C&W in this region.  We're very happy to
have C&W as a sponsor for the meeting, and I'll turn it over to you.
SPONSOR PRESENTATION 
              Jenson Sylvester:  Thank you very much.  Thank you, John. 
Business partners, industry friends, ladies and gentlemen, good morning.
 
              All:  Good morning. 
              Jenson Sylvester:  Welcome to Barbados.  It gives me great
pleasure to join you today as Barbados' leading telecommunications
provider reaffirms its working relationship with ARIN.  
              This location is a doubly special moment for both ARIN and
cable and wireless as together we were able to create history last
month, with the first-ever commercial deployment of IPv6.  
              (Applause.) 
              I'd like to thank our local team headed by Shawn Holder
for all the hard work and effort in pulling this off.  It's a true
testament to the strength of our collaboration in further accelerating
the potential of individuals, organizations and our wider Caribbean
community.  
              As you know, cable and wireless has been providing the
people of Barbados with reliable connections for more than a century
now.  And as we look to the future, we are pleased to say that we are
now on the cusp of offering the facility of IPv6 to our entire B2B
customer base.  
              Over the years, we've been laying the foundation for the
fully connected environment which we all now enjoy.  
              At the same time, we continue to invest in our networks
and people.  And we will also continue to place our focus on innovation
to the benefit of all Barbadians who every day display great aptitude in
leveraging technology for future development and growth.  
              Of course, like ARIN, we do this in the belief that our
ability to positively influence society feeds directly into our own
success as an organization.  
              This is why we tip our hats off to you for structuring
ARIN as a service-oriented organization that is responsive to the needs
of the public and is totally driven by a community of end users.  
              Likewise, we are also very proud of our relationship with
the local business community, in particular, the local education
hospitality and financial sectors.  
              And we stand ready to work with all stakeholders to see
that their respective projects become a reality in the shortest possible
timeframe.  
              As Barbados' leading telecommunications provider, we are a
company comprised of history makers and future enablers.  And we are
acutely aware that connectivity and the access to reliable connections
has become the glue that binds us all and brings us closer together.  
              So to the folks at ARIN and our other industry partners,
we say thank you for providing us with a platform that connects us all
to the future.
              Please enjoy your time in Barbados, and we certainly look
forward to our sustained collaboration in the coming days and beyond. 
Thank you.  
              (Applause.) 
              John Curran:  Next up I'll have Richard Jimmerson come up
and give our Regional Policy Update.
REGIONAL POLICY UPDATE 
              Richard Jimmerson:  Good morning, everyone.  One of the
standing agenda items that we have at each public policy meeting, right
at the beginning, at requests year over year, is a brief description of
what we have in regard to policy discussions in the other regions.  
              So this discussion that we're having in the room here
today happens all over the planet throughout the year, also in the
AFRINIC region, APNIC, LACNIC and RIPE NCC regions.  
              Now, there's a slide at the end of this presentation, if
you want to go to their sites where all these policies are described for
more information, you can do that.  But in the AFRINIC region right now,
they're talking about making multi-homing not required for AS numbers,
clarification on temporary resource usage, Internet number resource
review by AFRINIC and an abuse contact policy update.  
              Also, they're talking about clarification on IPv6
sub-assignments, inter-RIR resource transfers that a lot of us use today
inside the ARIN, RIPE and APNIC regions; Soft Landing Update for their
last block of IPv4 address space; and AFRINIC Policy Development Process
in general changes, changes to that.  
              In the APNIC region, they're talking a bit to that
validation of the abuse mailbox and other incident response team emails.
 That's consensus at their last meeting.  
              They did not reach a consensus in the last meeting about
clarification on IPv6 sub-assignments or the Policy Development Process
update.  A new proposal on modification of transfer policies is up in
that region.  
              In LACNIC they're talking about mergers and acquisitions
all the way throughout for AS numbers, IPv6 and IPv4.  And, in addition,
they're talking about IPv4 resource transfer policies comprehensively,
in general, and the inter-RIR transfer policy.  So they're looking to
join the three existing regions with inter-RIR transfers -- Acceptable
Use Policy for the policy list, too, where there's communications going
on there between members of the community.  
              RIPE NCC's talking a bit about Internet Routing Registry
database nonauthoritative route object cleanup, clarification of
definition of assigned provider allocated addresses, reducing IPv4
allocations to a /24 and BGP hijacking as a RIPE policy violation.  
              If you want to look at any of these in detail, to set
context for some of the discussions that we may be having here inside
this region, you can do that, and you can find that information easily
at their websites listed here.  Thank you very much.  
              John Curran:  Any questions for Richard?  
              (No response.)
              Thank you.  
              (Applause.) 
              Next up, Tina Morris, the AC chair, give the On Docket
Report.
ON DOCKET REPORT 
              Tina Morris:  Good morning.  The AC has an incredibly busy
docket right now.  We have three policies in recommended draft state. 
That means after this meeting they could be sent to the Board for -- I'm
sorry, sent to the community for Last Call and then adopted to the Board
-- sent to the Board for adoption.
              We have eight draft policies under discussion right now. 
These are policies that we're still working on the language.  We're
still looking to see if there's community support.  We're still just
working on them in general.  We have one editorial change and one
proposal that has not yet made it to draft status because the shepherds
are still working with the author.  
              Recommended Draft Policy 2017-12 was actually remanded
last July for the AC to look at because the impact was considered
extreme.  Since then we've redone the language a bit and it's in new
format.  It requires ARIN to identify and contact organizations related
to points of contact before they're put into the database.  
              2018-2: Clarification of ISP Initial Allocation is meant
to change how the block sizes and the language of the initial
allocations are presented in the NRPM to clarify.  
              2018-5: Disallow Third-party Organization Record Creation.
 It's meant to address Whois entries that are not authorized by the
recipient of the addresses.  
              2018-6: Clarify Reassignment Requirements in 4.2.3.7.1
specifies that not only a customer -- that only a customer's name is
required for assignments, also just to clarify policy, make sure
everybody understands simplify NRPM.  
              Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request
Requirements, unmet language, application to v4 space only, and that
they can't have recently transferred address space to another party.  
              2019-2: Waiting List Block Size Restriction, it addresses
the unmet request limit.  Currently there is no limit.  It reduces it to
a 22 or smaller.  Currently the waitlist is suspended.  This is one of
the policies meant to address that suspension in the fraud issues that
have been in play.  
              2019-3: IPv6 Deployment Block, adjusts the allocation
language concerning the dedicated v4 block to facilitate v6 deployment,
changing the minimum to a 24 and limiting the total to a 21.  
              2019-4: Allow Inter-regional IPv6 Resource Transfers. 
Currently v6 is restricted.  It cannot be transferred to another region.
 This would change that.
              2019-6: Longer Hold Time Requirements for 4.1.8
Recipients.  This is another one meant to address the issues with the
waitlist, changing the wait time from receiving the space from 12 to 24
months.  
              2019-7: Elimination of the Waitlist is yet another one,
trying to address the waitlist issues.  This removes the waitlist for
IPv4 requests entirely and replaces it with an auction procedure
administered by ARIN.  That one should be interesting.  
              2019-1 is an editorial change.  We won't be discussing it
at the meeting.  But it is in Last Call to the community.  And it's open
for input until April 25th.  
              These are not on the agenda, along with the current
proposal that hasn't made it to draft state.  
              Draft Policy 2019-5, we're still working on the language. 
It's not quite ready to be presented to the community; it will be
presented in October, and it will be on the PPML.  
              2019-1 is an editorial change which we don't generally
present.  Thank you.  
              John Curran:  Any questions for Tina?  
              (No response.)
              (Applause.) 
              Thank you.  Next I'll have John Sweeting come up and give
the Policy Experience Report.
POLICY IMPLEMENTATION AND EXPERIENCE REPORT 
              John Sweeting:  Thank you.  Good morning, everyone.  I'm
John Sweeting.  I'm Senior Director of Registration Services.  I'll talk
about a few issues concerning policy, current policy that my staff finds
to be either vague or contradictory to what we think that the community
is really trying to achieve with those policies.  
              So, as you see here, policies that aren't working as
expected.  We do this based on customer feedback that we receive daily
at the RSD help desk through calls, tickets, emails.  
              And it's also we also have some ideas for new policies
that come in every once in a while, which we just feed over to the
Advisory Council.  
              For the ones that I'm going to talk about today, the
community, you're the ones that actually have to decide what we need to
do with them, how we need to change them or not change them, depending
on what you feel you really want those policies to achieve.  
              So the policies I'm going to review today are 4.10:
Dedicated IPv4 Block to Facilitate IPv6 Deployment, as well as 4.5: The
Multiple Discrete Networks; and also 6.5.8.1, your IPv6 Initial
Assignment Criteria.  
              Okay, so 4.10 is the dedicated IPv4 block that we have set
aside to facilitate IPv6 deployment.  It reads in part:  "In order to
receive an allocation or assignment under this policy, the applicant may
not have received resources under this policy in the preceding six
months."  Another tidbit is you can only receive a /24 at a time.  You
can only qualify for a /24.  
              Six months later, if you're using 80 percent of that block
for the purpose of IPv6 -- to assist in IPv6 deployment, you can apply
and receive and be approved for an additional /24.  That can happen
every six months.  
              Under Multiple Discrete Networks:  "Upon verification that
the organization has shown evidence of deployment of the new discrete
network site, the new network, or -works, shall be allocated the minimum
allocation size under Section 4.2.1.5."  
              So the problem that we have here is if you are a multiple
discrete network and you come in and get a /24 for a site to
transition -- to help with your transition to v6, if you have another
multiple discrete site that you're deploying v6 at, you cannot receive
-- under current policy, you cannot receive another /24 to help deploy
v6 at that site unless you wait six months.  
              This is becoming more -- we've had more questions about
that.  Even though we haven't actually encountered an MDN request for
4.10 space, it's because we've been asked the question, told that -- and
the answer has been that they can't apply for it.  
              So my staff brought it to me, and I said that doesn't
sound right; that doesn't sound like the intent of the community would
be to not -- if somebody has a multiple discrete network that's been
recognized and they have a need at those different multiple discrete
networks to have a /24 for the deployment of v6, we've recognized it as
multiple discrete networks, we've recognized they may be announced as
different upstreams, it just didn't seem like it jibed with me that
that's really what the community would want and that's how they would
want us to treat that.  
              So the questions that we have for you, the community, is
should each autonomous network be reviewed separately under multiple
discrete networks?  Does the 4.10 six-month requirement apply to the
organization as a whole, or should we apply it to multiple discrete
networks, the networks within the organization rather than the
organization as a whole?  
              Today, absent community input on this, we're interpreting
it to mean that we can only allow one /24 per six month per MDN to the
organization.  
              As I said, that's not exactly what the policy states
today, but that's how we're interpreting it.  And we really would like
feedback to make sure that we are enforcing that policy as the community
wishes it to be enforced.  Our thinking is that we really -- we don't
want to stand in the way of IPv6 deployment.  So if somebody has a need
and we've already recognized they have that need for the multiple
discrete networks, that we should allow them the block at each of those
sites, the /24 at each of those sites to help them deploy.  
              Cathy has a question already.  I haven't even called for
questions.  Go ahead, Cathy.  
              Cathy Aronson:  I can wait if you -- I'm Cathy Aronson. 
If they have two different Org IDs, can they get two different blocks
under that policy?  
              John Sweeting:  Yes, absolutely. 
              Cathy Aronson:  I would be under the opinion that if they
have MDNs, they should be able to, too, but anyway, thanks.  
              John Sweeting:  Thank you.  
              Chris.  
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC. 
The multiple discrete networks, I have a history because I worked for
the company that got that into -- that worked to get that into the
policy.  
              The target, the target of that policy language was
intended for organizations that run effectively BGP islands -- so that I
have AS number one over here, AS two over here -- are completely
separate.  They can be treated as separate entities for the purpose of
qualifying for v4 space.  
              Just to add some background to that.  So my impression is
that, given the ambiguity, you're following the correct policy. 
              John Sweeting:  Okay.  Thanks, Chris.  
              Kevin.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. To me, these
are two separate policies and commingling them actually affects one of
the inputs related to 4.10, which is that we're giving out last little
bits to organizations that need a kick-start with v6.  
              Without having statistics on the number of Orgs with MDNs
and the number of MDNs that they have under their portfolio, it seems
like one Org could use this as a way to jump-start their entire network
with v4 using v6, which is great, but deplete this pool significantly. 
              I don't know what the largest number of MDN sites under
one Org is, but if each one is treated separately it's a fairness issue.
 For me 4.10 was meant to be for -- not for small organizations but for
an organization to get a kick-start for v6 by getting v4.  
              We're giving now a thousand, if you had -- I don't know if
there's an MDN with a thousand 64, 128, whatever it may be, times that. 

              That doesn't seem quite right.  I would expect that 4.10
should be an isolated policy and not pulling in things like MDN. 
              John Sweeting:  You're stating just per organization.  So
we just make them get Org IDs for each one of their discrete sites
rather than keep it simple?  
              Kevin Blumberg:  I think there's a complexity with MDN
that shouldn't be intertwined into.  Like I said, without some real
statistics on this, I'd rather see 4.10 left stand-alone and not apply
things like MDN into 4.10 which would effectively mean one Org ID would
be allowed to get the space from there.  
              John Sweeting:  And we do have statistics on the size of
the 4.10 pool.  
              Kevin Blumberg:  Not the 4.10 pool.  The MDN.  How many
Orgs have MDNs and the number of MDNs that they have. 
              John Sweeting:  Okay, we can get that.  
              Kevin Blumberg:  Thank you.
              John Sweeting:  Back mic.  I'm sorry.  It's just hard to
see.  The sun is bright here. 
              Michael Casadevall:  Michael Casadevall, NARALO.  Do we
have current statistics on what is currently available in the 4.10 pool
and projections towards exhaustion since that, I think, would influence
the policy decisions?  
              John Sweeting:  Yeah, I'm going to give that in the RSD
department update.  I believe it's somewhere around 98 percent of that
pool is still available.  
              Michael Casadevall:  All right, thank you. 
              Owen DeLong:  Owen DeLong, ARIN Advisory Council. 
98 percent could go away very quickly if we start issuing additional
/24s for MDNs and people decide to use that liberally.  I'll avoid the
word "abuse" for now.  
              I personally think that expanded 4.10 to MDN might not be
such a bad thing if we use the Policy Proposal that is currently on the
docket regarding 4.10.  One of the side effects is capping the total
amount issued to any one Org at a /21.  And I think once that safeguard
is put in place, it's probably not so bad to allow Orgs with MDNs to get
multiple /24s based on their MDNs up to a total of a /21.  
              I think allowing any Org more than the /21 out of 4.10 is
completely contrary to the intent of 4.10, even if they have a thousand
MDN sites.  I really wouldn't want to see that happen.  
              John Sweeting:  Yeah, just realize, as Cathy brought up,
that these organizations could -- instead of doing it under multiple
discrete networks, they could just have a separate organization
registered with a separate Org ID and get those ASes for those sites
under that Org ID and qualify.  
              So just keep that in mind because I think Cathy kind of
hit the nail right on the head with that comment.  Andrew.  
              Andrew Dul:   Andrew Dul, multiple discrete network guy
and ARIN AC.  My thoughts about this are when we did 4.10 originally, I
don't think we considered this as an intertwinement and we wanted 4.10
to stand on its own.  So my interpretation of 4.10 is that it should
stand on its own today.  
              And I would encourage people who would like to apply
MDN-type methodologies to 4.10 to make a comment on the existing Draft
Policy that I authored to update 4.10 based on information that John
brought to us, John Sweeting brought to us in the AC in January in
face-to-face meetings.  
              So please make comments on the Mailing List for the draft
that's outstanding right now.  And if you feel strongly about this, we
can include this in that draft update.  
              I don't have that policy number off the top of my head. 
But it is one of the drafts that we will be discussing today and
tomorrow.  
              John Sweeting:  Thank you, Andrew.  And just a little bit
-- go ahead, John, you go first -- I was just going to say the three
queries we've had into this have been from organizations that had two
multiple discrete networks.  
              John Curran:  Any other questions for Mr. Sweeting?  Thank
you, John.  Round of applause for this one.  
              (Applause.) 
              He's not going anywhere because now he's going to give the
Internet Number Status Report.
              John Sweeting:  I actually have another policy -- the
questions -- so this is on initial assignment criteria for IPv6. 
Organizations may justify an initial assignment by having a previously
justified IPv4 end user assignment from ARIN or one of its predecessor
registries.  The problem we're having with this is that this policy was
written prior to depletion.  
              It doesn't really tell us how to interpret it in the case
where an organization cannot qualify due to the depletion -- not that
they can't qualify -- well, they can't qualify for the IPv6 but they can
qualify for IPv4, but they can't get IPv4 because they have to go on the
waitlist.  
              So the questions for the community is can the current
practice -- is the current practice correct?  If so, it might be wise to
formalize it in a policy.  If not, then guidance should be provided.  
              And what we're doing today is that if they qualify for v4
and they're on the waitlist or they're waiting for a transfer, then we
say they qualify for v6.  
              In other words, we can go with status quo.  Qualifying for
IPv4 qualifies you for IPv6 or other options.  And if that is correct,
then possibly it should get updated in policy to reflect that it's not
just that they have v4 but that they qualify for v4.  Owen.  
              Owen DeLong:  Qualifying for v4 was one of many criteria
by which you can qualify for v6.  So -- or having v4, rather, was one of
multiple criteria by which you can qualify for v6.  
              I think the other criteria by which you can qualify for v6
are perfectly adequate and that I'm fine with the staff interpreting
qualifying for v4 qualifies you for v6 because I agree that
circumstances now were not envisioned at the time of writing of the v6
policy.  I had some hand in writing the v6 policy.  So I will admit
that.  
              But I do think that the other criteria are adequate to
cover most initial circumstances where an organization doesn't have v4
or isn't getting v4. 
              So I'm not sure policy work is really necessary here.  
              John Sweeting:  So, you're saying just the status quo on
continuing marching where we're marching?  Fine.  
              Thank you.  Any other questions?  If not, as John said,
I'm going to stay right here and go into the Number Resource statistics
overview.  There you go.  Thank you, Kerrie.  I'll give the Internet
Number Resource Status Report.
INTERNET NUMBER RESOURCE STATUS REPORT 
              So this is just a representation of the distribution of
the 256 /8s from IANA.  Also, if you remember right, some of you will
remember at our last meeting, it was requested that we give a
representation of where all the space is today because it's due to
transfers and everything.  
              We don't have that slide yet.  That slide will be in the
next presentation that's generated by the NRO.  So at our fall meeting I
will have a slide that speaks to that.  
              This is a representation of the total IPv4 addresses that
are managed by each of the RIRs.  As you can see, ARIN is way up there,
but a lot of that is due to the legacy.  Half of our space is legacy
space as just about everyone is aware of.  
              So that's why that, the 99.8, whatever that is, thousand,
million, anyway.  
              Available IPv4 space in each RIR.  This is space that's
available for them to be given out.  You have your last /8 policies in
place at RIPE and APNIC and LACNIC.  AFRINIC and LACNIC actually still
have a little bit of space left.  They haven't hit depletion, but
they're into some of their special policies that cover those last
portions of IPv4 space that they have available.  
              So in terms of /8, this is just a historical
representation of the space that each RIR has issued per year going back
10 years.  As you can see, it's gotten down to where it barely shows up.
 
              IPv4 transfers.  This does not include your merger and
acquisition transfers.  Number of transfers per year.  Of course, it's
going up and up and up.  
              The number of addresses transferred by year, it goes up
and down.  The number of transfers keeps going up, but the number of
addresses fluctuates.  Some years we have some really big deals where
one or two /8s change hands through transfers and other years we don't
have those big deals.  
              And those /8 transfers actually cause a big spike in, of
course, the number of addresses that are transferred via the transfer --
the M&As.  
              So the inter-RIR IPv4 transfers.  This is representative
of the number of transfers.  What's more interesting to everyone I'm
sure is the total number of IPv4 addresses transferred between the RIRs.
 
              As you can see, ARIN and our legacy pool, which a lot of
people refer to as the free pool for the transfer market -- although
it's not a free pool -- but it's the transfer market pool that has
replaced the available addresses.  So available addresses for the
transfer market really come from that pool of legacy space, which ARIN
is by far the largest holder of legacy space.  
              So you can see we have sent 16.6 million IPs to APNIC and
received back 118,000.  We've shipped off 8.8 million to RIPE and got
back 299,000.  And then you see between APNIC and RIPE it's pretty even.
 They pretty much go back and forth with each other, 1.9 million from
APNIC to RIPE and 1.4 million from RIPE to APNIC.  
              Moving on to the IPv6 statistics.  This is a
representation of what has been allocated to the RIRs from IANA.  There
was some early space that was given out that I believe is broken down in
that last yellow ring.  You've got an IETF reserve in there.  You've got
a 6to4 /16 in there, allocated to RIRs before they went to the /12 as
being the size that they give to each of the RIRs.  And then up in that
little box you see each of the /12s that have been given out to each
RIR.  
              As of today, no RIR has gone back for an additional /12. 
RIPE is very close to doing that.  But they had some other things they
needed to do before they actually went in and requested that and it was
due -- I don't know if anybody's paid attention to some of the Mailing
Lists in IANA, there was a small block, I believe a/23, that was stuck
at IANA that was reserved for RIPE, and actually RIPE had it reserved
for one of their larger customers.  But it was tough for IANA to get
that to RIPE because there wasn't a policy in place, a global policy
anymore that allowed them to do anything but /12s to the RIRs. 
              So they got together.  They came to the NRO NC, who
conferred with the RSCG, which is the Registration Services Coordination
Group.  We all looked at it and decided that the best thing to do would
be to take that/23 and do what was intended back prior to the /12 policy
being passed, and they issued that to RIPE.  
              RIPE could not go and get that /12 prior to that because
they wouldn't have been able to qualify for anything for IANA; it would
just make things more difficult. 
              So I would suspect that they will be going in for the
first additional /12 sometime this year, and we're not too far behind
that. 
              This is IPv6 allocations issued by RIRs.  As you can see,
APNIC has been allocating the most with LACNIC.  LACNIC is -- they're
interesting there because I believe it's like 90-plus percent of their
members have IPv6.  But there should be nothing too questionable about
this.  
              Total allocated IPv6 space per RIR, which RIPE's leading
there.  APNIC has the 75 million -- 75,000 /32s.  ARIN, LACNIC and
APNIC, so even though LACNIC has a big high percentage of their
membership, it's not that much space.  It's not as much space as the
other RIRs, I should say.  
              This is per year.  The prefixes that each RIR assigns per
years.  So, rather than allocation and assignments.  And this is the
total size of IPv6 space in /48s that each RIR has assigned.  
              So you saw for the allocations we reported it in /32s
because that is the primary unit that is issued, allocated.  And in the
assignments we report it in /48s because that's the most prevalent and
most policies refer to that.  
              Percentages of -- here you go, here's the percentages of
members with IPv6 in each RIR.  The pinstripes there, the top part of
the numbers are members with IPv6 only.  
              One thing to remember on that is just because we show they
have IPv6 only from ARIN doesn't mean they only have IPv6 and they don't
have IPv4.  They could have IPv4 that was assigned or allocated to them
from their upstream but then they came to ARIN to get their IPv6.  
              So it's hard to tell.  We couldn't really tell you
definitively if there's anybody out there that only has IPv6 and is only
building their network and deploying their network with IPv6.  
              Nobody has claimed that as of today, so I'm not sure if
there is any cases of that.  But from ARIN itself, directly from ARIN we
have 9.6 percent of our members have IPv6 only.  
              Moving on to the AS numbers.  This is a chart of all AS
numbers with the 16-bit numbers broken out there in the circle on the
side.  
              I don't think there's a whole lot really interesting
things to talk about there.  Unless somebody has questions, then I'll
answer them when I finish with this, and you can ask your question.  
              How many ASNs has each RIR issued per year?  It's pretty
steady.  And it doesn't seem to be going down.  It hasn't gone up much,
as you can see.  Like I said, it's pretty steady.  
              ARIN, of course, gives out more 16-bit than most of the
other ones only because we have the larger pool of them.  Again, it's
back to the legacy stuff from the early years and all that.  
              Total ASNs assigned by each RIR.  You can see ARIN there
in the middle in the Syracuse orange.  Or you could say Virginia orange,
I guess -- okay, Susan.  I'll plug you.  Virginia's playing tonight for
the national championship.  So everybody root for Virginia, unless
you're from Texas.  
              And these are the references.  These stats, this
presentation is posted to the NRO site.  And that's it.  Any questions
on that?  
              (No response.)
              If not, then I will depart the stage, I think.  
              John Curran:  Any questions for Mr. Sweeting?  
              (No response.)
              Thank you, John.  
              (Applause.) 
              At this time I'd like to have Cathy Aronson come up and
give the IETF Report.  Pleased to say Cathy is our IETF reporter, and
she goes traveling the globe and I guess entertaining herself in IETF
meetings with all sorts of interesting characters in order to bring you
this report.  So, thank you, Cathy.
IETF REPORT 
              Cathy Aronson:  Hi, everybody.  I tried this time to --
oh, God, that's like an inquisition light or something.  
              (Laughter.) 
              I tried this time to actually have photos from the IETF
and not from my backyard and stuff.  
              This is actually from Prague, which is a wonderful place,
if you haven't been.  
              So this presentation covers two IETFs.  There was one in
November in Bangkok and one a week ago in Prague.  So if you're looking
something up, just keep in mind that it might be -- it's all intermixed.
 So it might be from a different IETF.  And if you have any problems,
just let me know and I'll be happy to steer you to whichever one,
because it's all sort of melded together.  
              Let's see.  So a highlight.  I found out sort of
serendipitously that .horse exists.  Did you know that?  Anyway, if you
Google -- I mean you traceroute to bad.horse sometime when you need to
be entertained, it's pretty awesome and really funny.  Someone clearly
had way too much time on their hands out there on the Internet.  
              The other thing I never talk about in these talks is
there's this thing called PechaKucha that started at the IETF a few
years ago.  And they're really entertaining little presentations. 
They're sort of like bad attitude lightning talks.  
              And I wanted to just send you a pointer to those because
if you need a laugh and you wanted to see IETFers making fun of IETFers,
it's a really good time.  And it happens really late at night, and I'm
usually too jet-lagged to go, but I watch them online.  Those are
highlights. 
              Okay, so I started this a while ago because the chair of
v6ops has challenged us to read a draft a week before the IETF.  So I
read a lot of drafts.  And I don't talk about most of them.  But a
couple of them, this one pertains to this -- God, that's a little
puffy -- this one pertains to this group.  It's all about sort of a
survey of a prefix length given to end sites.  
              And the IETF has recognized that it's this community that
really makes the decisions about prefix length and who can qualify for
what.  But they also wanted to put together some information about the
percentages of different areas that use different prefixes.  
              And I'm going to talk some more about this later, but
apparently we have enough v6 for 102,400 years, which I think that that
math is probably a little bit suspect.  But it's an interesting quote
from the draft there, Maths Show, which is a good thing.  Anyway, that's
a good draft to read.  
              I read the SIP specification again.  I read it about a
million years ago.  But they just republished it as historic.  And it's
really one of the first attempts at IPv6.  Like what was going to take
over for IPv4.  
              And it's kind of entertaining to read.  And I read 464XLAT
because I really wanted to know what the acronym "XLAT" stood for, and I
still don't know.  But it's basically a way of v4 devices to connect
over a completely v6 Internet.  It's basically like a fancy NAT,
multiple layers of NAT that you use.  And it's used a lot in China
actually because they do a lot of v6-only networking now. 
              The IEPG is this mysterious group that's met for 20 years
the Sunday before IETF.  And I just found a long-term IETFer on my way
back from Prague who didn't know it existed.  So there's are a lot of
people at the IETF who still don't know it exists, even though they have
been attending.  But he wrote it down because he didn't want to forget. 

              It's a group of operators that meets -- maybe a few of you
are here, I don't know, sometimes Rudiger's here -- anyway, it's pretty
interesting.  I wasn't at the IEPG meeting in Bangkok because our plane
had a cracked windshield and we had to divert to San Francisco.  So I
missed it.  
              So the IEPG part is all from Prague.  So there's some work
being done to measure QUIC.  So QUIC is the new Internet protocol that
runs over UDP.  So instead of TCP -- I mean, TCP over IP, it's QUIC over
UDP.  
              And they're doing some measurements -- mostly this is used
heavily by Google and YouTube, a lot of the big content providers
because it's faster.  
              But apparently it's only faster if the packets arrive in
order.  And once the packets start being out of order, there are some
problems.  So there's some work being done to measure and figure out,
like, is it really better, is it not better.  So there's a link to that
information.  
              There was some talk about using BGP to blackhole DDoS
attacks using BGP communities.  There's a lot of work being done with
that.  And then trying to make sure that you can't maliciously use BGP
communities to blackhole traffic, because that's always an issue, too. 
So that was a presentation at IEPG.  
              So when a host gets disconnected from a network and a --
in v6 and it gets a new address via Stateless Auto-Configuration, it
doesn't let go of its previous address even though somebody else might
have that address.  
              So there's some problems -- there's a lot of various v6
deployment problems.  And this is one of them that's being documented
where you need to really be able to let go of the address that you just
lost because somebody else might have it and then you might not be able
to talk to the person who has it because you think you have it.  
              So this presentation was all about that.  Okay.  So the
IETF is trying a new approach where they're trying to get all the
stakeholders together for a particular part of the work that we do in
order to make it so that maybe we're not writing a standard VET chip
developers can't put in silicon or various things like that.  
              So the first one of these was this deep dive into router
architecture.  And they decided that the acronym stood for We've Got --
We Got Lego.  I don't know.  Kind of weird.  I don't understand how
WGTLGO means We Got Lego.  
              But anyway, it was a really interesting afternoon talk
about router architecture.  And some of the quotes, well, assuming a
zero-gravity router was irrelevant, but I thought it was funny. 
              But some of the realities are that the protocol designers
are saying we want a 128-bit, whatever, and the hardware designers are
saying we can't do that.  And there's this disconnect.  
              And so, like I said, some of these quotes are actually
really the heart of the problem that we have.  And so it was really cool
to have all these people in the room, even though everybody was a little
upset because the chip guys didn't want to do the 128-bit and the
routing guys are mad because the configs are humongous because they have
to do everything in an access list.  
              So it's kind of cool.  I think they're probably going to
do some more of these where we try to get everybody on the same page as
to soup to nuts from how the policy affects the people actually writing
the code and doing the hardware.  
              Okay.  So the key signing, key rollover, everybody knows
about that, right?  For DNSSEC, we rolled over the key.  We got rid of
the old key.  
              So in Bangkok, we had a meeting.  It was a preliminary
meeting to just talk about, okay, we rolled the key.  How often should
we roll the key?  Should we ever roll the key again?  It was a real pain
to roll the key, all that kind of stuff.  
              So they had the afternoon on Friday, they had no meetings
except for these side meetings.  So I went to this one.  
              And so these are all the questions that came out of that,
like I said, should we roll the key; should we roll it regularly; should
we never roll it?  They're still really trying to work that out.  
              And then that rolled into this Futures BoF that happened
in Prague just a week ago, which was a follow on of the same process. 
So now that we've not only rolled the key but we've made the old one
invalid, what happened, and what was the fallout?  
              And there were some people who talked about how there were
250 million users adversely affected, but I don't really -- but nobody
really knows, because the DNS is so dense and opaque, and it's really
hard to measure.  And maybe a lot of places just turned DNSSEC
validation off and left it off so they didn't have a problem.  
              So really trying to grapple with how do you measure these
things and figure out what happens when you roll the key and what really
is broken.  
              So it's a lot of work being done on that.  I'm not sure if
there are any really good answers at this point.  
              So DHC, Dynamic Host Configuration.  This is a little bit
from the chart.  All of these at the beginning have a little bit from
the charter so that you can know what the group is about.  But basically
this is DHCP in all of its forms and automatically configuring host
addresses.  
              It was started in 1989.  It's the longest running working
group.  And we're hoping that after November, when DHCPv6 becomes a full
Internet standard, maybe the working group will go away.  But that's
where we are at with that.  So, again, DHCPv6 isn't actually a full
Internet standard yet; it's just a draft standard.  
              So one of the things that DHC is working on is there's so
many devices on the Internet that are short-lived or they're Internet of
Things, little gizmos in your house.  And they don't really want to hard
code MAC addresses into those devices because, of course, just like IP
addresses, MAC addresses are a finite resource.  
              So stranding a bunch of MAC addresses in little gizmos
that you threw out the year before is probably not the best thing.  So
they're working on this whole link layer, being able to assign MAC
addresses with the DHCP instead of having them hard coded in the
hardware.  
              And half of the Mac address space was split into this
local amount of address space.  And it's broken into these quadrants. 
And so part of the protocol that's being worked on is how do you tell
the hypervisor board that it's this quadrant and then give out the MAC
addresses to the little devices.  So that's some work going on there.  
              So link-state routing I started following just because I
think that the data center -- link-state routing in the data center I
thought was interesting to follow because you have these really dense
data center networks and link-state protocols are really chatty.  
              So there's a lot of work being done -- almost kind of too
much work being done, like a whole bunch of protocols trying to solve
the same problem, just like we had with all the tunneling protocols to
get v4 and v6 working.  Now we have a whole bunch of protocols to make
data centers less chatty.  
              So that's mostly what these slides are about.  There's a
bunch of different modifications to the protocols so that there's less
flooding and so that your data center doesn't melt down when things move
around.  
              Let's see.  This is another algorithm for limiting the
flooding.  There's another hierarchy to IS-IS that's being proposed to
limit the amount of chattiness in your linked state protocol.  So that's
mostly what's going on in that group.  
              DNS operations is, of course, all about the operations of
the DNS system.  Everything that could go wrong and more about the key
signing key we talk about in there, that sort of stuff.  
              This draft we've talked about before basically lets
resolvers downstream from the root be able to serve stale data in case
the servers up above are being DDoS'd.  And that really makes a lot more
resilience in the DNS if you can at least use the information you have,
even if it's timed out, when you can't get new information.  
              Let's see.  This is a new record type in the DNS that
functions and -- ostensibly like CNAME does, but it gives you -- CNAME
has a bunch of limitations and can't exist with other resource types. 
So it's a way of updating the CNAME functionality so that it's more
useful for a bunch of different features that people are trying to do.  
              This is a way of locating -- okay, so for a while we were
trying to put everything in BGP, like adding more and more stuff.  And
now they keep adding more and more stuff to DNS.  So this is adding
different services that you could find but adding it to the DNS.  So,
like, you could find your blockchain in the DNS, and you could find
various other infrastructure and people and stuff in the DNS.  I'm not
sure how far that will go.  But we'll see. 
              These are some other drafts I'm not going to talk about
that are going on in v6ops.  
              So they stopped having the technical plenary, but I always
go to the plenary.  And this time it was all a bunch of record keeping
and this and that, but this slide I just think is hilarious.  
              So basically this is a sign on a building that basically
says nothing ever happened here and hopefully nothing will ever happen
here in the future.  I just think it's funny.  Sorry.  A little levity. 

              Okay.  So computing in -- so there's the IETF and the
IRTF.  The IRTF is a resource forum that works in parallel with the IETF
and does things that maybe the IETF isn't quite ready for.  
              And occasionally -- well, I go to the IRTF working group
to see more, like, futuristically what's coming down the road.  And this
research group is all about moving, computing as close to the end as
possible, so out in the network, having your switch do things that are
closer to you.  
              And the concept is that the edge is constantly changing. 
The edge of the network isn't really the data center anymore.  It might
be your neighborhood or it might be various community groups or
whatever.  
              And so, for example, in industrial networks, you know,
that second that you're talking to the thing that's welding the part,
maybe you really want it to only be a second delay, not a 20-second
delay to go up to some data center. 
              They're working on ways to push computing closer and
closer to the actual thing that's moving that you're trying to make work
out on the network.  
              Like I said, neighborhood clouds is another computing
concept that they're working on.  Like, maybe things happen more -- we
still, we already do this, right?  Your little cable modem at home does
your DNS for you and it does your NAT for it.  And it does little bits
of computing that you don't have to go all the way up to your ISP to do.
 
              And this is sort of more of that.  And I'm not sure that
like a lot of those little devices and routers and stuff will be able to
do any of this computing.  But it's a really interesting thing to think
about.  
              Okay.  So operation security is exactly what it means. 
It's all about security out on the network and securing the network.  So
this is a draft that started quite some time ago, and it's almost ready
to be published.  So if you're interested, you should check it out.  
              We asked that they remove references to PI address space
and some things that affect this community because they really have
nothing to do with security.  They have a lot to do with whether you can
move your stuff from one ISP to another, but that's not really a
security issue.  
              So they're cleaning up some of those things.  And then
this should go out for Last Call pretty soon.  Since 2012; I think it
might be time.  
              And in v6 Operations, so there's -- v6 Operations is
just -- it's all about operating a v6 network and the interaction
between v6 networks and v4 networks.  And I'll talk about the partner to
this group in a little bit.  That's what v6ops is.  Anything we need to
make v4 and v6 work or to make v6 work operationally is what this group
does.  
              Let's see.  This is getting your NAT64 prefix from your
router.  So when you're just a v4-only host, you need to get an address
to get on a v6-only network.  And this is the protocol to allow that
easier than now.  
              This is real life.  They do a lot of v6 in China.  And
this is a survey of CERNET2, which is a big education and research
network in China, and they're not at all dual stacked.  So they do v6
natively and then they translate on the edges.  And they're working on
ways to make it so that they're not doing multiple v4 to v6 to v4 to v6;
they're just doing one translation and then going to the other end and
untranslating.  
              Let's see.  So this is deployment guidelines if you're
going to do translation.  So like if you have a v6-only network and
you're going to -- you still need your v4 stuff to talk to the rest of
the Internet.  There are operational considerations that you should
check out that might help you in deploying.  
              And then the partner one to this is a comparison of all
the transition mechanisms that you could use if you have a v6-only
network and you want to make sure that all your v4 hosts will work.  
              And a lot of these are being used.  There's been talks
that I've given before different organizations that are using MAP-E or
MAP-T, and this is basically a comparison of all the different
mechanisms.  
              So, again, this is more translation information for CDNs. 
And so the IRTF, like I said, is the research forum.  And there's a
contest every year of papers that are like -- they win the research
award, Advanced Networking Research prize.  And some of these are really
great.  I always try to go to this because the papers are really
interesting.  
              This is all about -- Facebook built this.  They call it
Edge Fabric.  Basically it's a real fancy -- I'd call it maybe a route
server that takes a whole bunch of notice of the speed and the bandwidth
and the congestion on the different paths and then routes the outbound
traffic based on different criteria.  
              And they've had some really good results.  I worked at a
company that did something similar, like, in 2002, and it can be really
helpful, especially in their case because all of their customers are
just sucking down a lot of data.  
              If it was -- so they're optimizing the traffic from their
customer to them -- from them to their customer, sorry, because most of
the bandwidth goes that way.  
              So this is a really interesting talk.  And then this is
all about BGP communities and how far they propagate in the network. 
And I took out the slide -- there was a little bit of a talk about this
in IEPG as well. 
              I only have 60 slides this time because I tried to get rid
of as much duplication as I could.  But BGP communities are used a lot,
and they go really a lot further in the network than people think.  And
it's kind of a little bit scary.  So that was cool.  
              Let's see.  And then they also talked about QUIC -- again,
that new protocol -- and just how does it work with -- compared to TCP
and does QUIC on the network affect TCP performance.  
              So there's a ton of work being done now that it's being
used fairly widely.  There's a lot of implementation.  
              So this was about that.  And then I went to this group,
MAPRG, basically measuring different protocols.  And I think they talked
about QUIC, too.  But I took it out.  
              So there's privacy and security in v6 networks.  That was
a talk that they had.  And, again, more QUIC performance over satellite
this time.  
              And some other measurements that they're talking about in
the group.  So Homenet.  I'm probably going to phase out going to
Homenet because they're as far as they're going to get for a while, and
they're going to do marketing slides how they get more people to do
Homenet, which is kind of -- so, yeah.  
              And there's some -- I think we really have -- because a
lot of the v6 networks are dual stacked with v4, a lot of -- we have a
few problems because of that, but it hides a lot of things. 
              And a lot of these -- they're starting to do these home
networks that are v6-only, and there's a lot of problems, like how do we
secure it, how do we send keys around, what do we do when there's
nothing there to configure it.  
              So they're starting to look at like having a code on a
device like a bar code that you scan, and then the network knows, oh,
that's a legitimate gizmo that you're plugging into your network and
that does whatever and that's how you can configure it.  
              It's just hard to try to standardize something that
there's no one physically there to configure.  So I don't know.  But
having keys and credentials for different things that get sent into a
Homenet.  
              How do you get your naming, all that stuff, is still being
worked on.  And they're not easy problems to solve.  
              Okay.  So like I said, v6ops is all about v6 and v4
interacting in the network and making sure that it works.  
              And v6MAN is all about just v6 protocols so the real
protocol work happens in 6MAN.  They're putting out a node requirement
draft, and I think I've talked about it a few times since I've done this
presentation, and the segment routing header.  I'll have a rant about
headers in a little bit.  They're starting to finally finalize those.  
              So if you're a v4-only host and you connect to a v6-only
network, this is a way that the network can tell you don't sit around
and wait and wait for the timeout to get your v4 address, because you're
never going to get a v4 address, just go and use v6 already, because
that's all there is.  
              So this is something that the v6-only networks have really
experienced.  Like a v4-only host takes forever -- like a host that
starts out as v4 takes forever to come up and use v6 because it has to
timeout, and it shouldn't have to.  If you're only v6, you should just
use v6.  
              My little rant about headers.  We were having a discussion
about MTU, minimum packet size on the network, and how it's really out
of date because it's an IEEE standard and Ethernet is 1500 bytes.  And
with v6 and all the headers and all the stuff, the packets are huge. 
And the network, there's still no good way to discover what the minimum
packet size you can -- I'm sorry, what the maximum packet size you can
send without it getting fragmented and not working.  
              So there are two different options being worked on in
6MAN.  One is the hop-by-hop option where you discover your MTU on hop
by hop.  And there's a "Packet Too Big" message thing that happens
and -- I think I skipped it; I think it's this slide -- no.  I'll get to
the other one.  
              So there's quite a bit of work being done on that because
in reality packet size should be like 9,000 bytes.  And as the lengths
get fatter and fatter, you want bigger and bigger packets so you can
more effectively fill the link.  So we have to figure this out at some
point. 
              And as we add more and more headers and we do more and
more tunneling and all those sorts of things, the packets just get
bigger and bigger.  
              Let's see.  So this is a big discussion about how to
generate these kinds of Stateless Address Auto-Configuration and how to
get your -- I guess I already talked about your NAT64 prefix from your
router advertisement.  A lot of this stuff gets presented in multiple
groups, so I try to figure it out -- I mean filter it out.  
              So this is the segment routing header, another thing
that's going to make the packet even bigger.  And it's almost going to
Last Call.  And there's several implementations now.  So it's probably
going to happen.  
              And, again, now this is the other MTU discovery mechanism
which is a "Packet Too Big" message that gets sent back.  And the
truncate -- the truncate bit's set, and then you know that you have to
send a smaller packet.  
              And these are some other drafts that are going on in 6MAN,
another MTU draft and some various other things.  
              So Global Routing Operations, I go to this occasionally
because I like to see kind of what's going on out there in the operator
world of routing out on the Internet.  
              Let's see.  So like I said from that other paper, there's
a little crossover here.  There's communities everywhere.  They
propagate really far.  And there's a lot of ways to hack that and
blackhole traffic that are really big concerns for the operator
community, and they're starting to work on ways to prevent those sorts
of hijacks. 
              Let's see this one.  Using BGP measurement protocol to
make sure that your prefixes go where you want them to go is what this
one was about.  Since we don't really -- we haven't really rolled out
BGP security on a really big level yet.  So they're trying to detect
route leaks without the humongous access lists.  
              So this group is new, and I just wanted to point out that
it exists.  And it's basically about securing all those little Internet
of Things devices in your home and keeping them from being bots and
spreading porn and whatever they do.  
              So they're just starting to form like an architecture and
information model and some various things.  And they do a hack-a-thon
before the IETF, and they're starting to do a hack-a-thon of this
securing of the Internet of Things.  
              So when there's no IPv6 something going on, I go to some
other group.  And this was some afternoon session that I sat in on.  
              So for those who aren't friends with me on Facebook, you
missed my awesome live streaming from the IETF on my Facebook wall,
where I go on and on about what is the quantum Internet anyway. 
              And one of my friends on Facebook, of course, is in charge
of the research group.  So she made a tutorial just for me.  So I'm
supposed to know now what the quantum Internet is, but I'm still
baffled.  
              So there's some of my notes from the Quantum Internet
Research Group.  I really do keep pondering:  What is it anyway?  Maybe
if you're a physicist and you talk really slow, you can help me.  I
don't know.  
              But so they did have a tutorial in Prague on what is the
quantum Internet, and I'm still -- to me, right now, the quantum
Internet is massive distributed computing, where you're connecting a
bunch of different research facilities over the Internet.  
              But I do understand that in the future we'll be sending
around things that it never occurred to us that we would be sending
around on the network, I guess, maybe.  
              So I did a big road trip recently.  And I listen to a lot
of NPR on my road trips.  And I don't know, you guys probably all
remember people in this room saying that with v6 it can address every
grain of sand on the planet.  
              And I always joke that that's all fine and good, but if
you give it away a beach at a time, it goes away really fast. 
              So I was driving back from California, and there was an
NPR -- it's so perfect for the Caribbean -- there was an NPR thing on
the radio about how in Jamaica there's this beautiful white sand beach. 
In the middle of the night, they came with helicopters and bulldozers,
and they just took the beach away.  And there's this whole sleuthing
thing going on trying to find where the beach went and who stole it. 
They haven't solved that yet.  
              But it got me thinking.  It woke me up in the middle of
the night because like we're actually using sand faster than the planet
can make more sand.  And when you take sand and you make it into
concrete or whatever, you can't get that back and readdress it and use
it again. 
              And I just thought it was sort of a metaphor for v6.  Like
we might be addressing things that we never thought of.  We might be
using it to make things we never thought of, and to say that we have
12,000 years' worth is probably not realistic.  
              And so I just -- I don't know, I thought it was hilarious.
 So if somebody is from Jamaica and you know where the beach went --
they're thinking that the resorts on the other side of the island stole
the beach, but they mix it in so the forensics guys can't tell whether
it's the white sand from the other side of the island.  
              Anyway, it just made me think about v6 and how we think we
have an infinite amount.  Like you think we have an infinite amount of
sand, but we don't.  Anyway, onward.  It's your thought for the day.  
              All of these, the Datatracker and all these things are
really good references if you want to go check out the IETF.  
              And if you're going to go to the IETF, please talk to me. 
I'm happy to help be your mentor or whatever.  And there's also some
good information online about how to attend an IETF and not be offended
by the geeks and all that sort of stuff.  
              So, I've been to Prague four times.  And I didn't ever
really realize that the grand ballroom has this awesome mirror in it. 
So this is actually an IETF working group and guys standing at the
microphone to ask questions.  I just thought it was awesome.  I, like,
perched in the corner.  
              Anyway, questions, comments, if you were there and I got
something vastly wrong or whatever?  
              Kevin Blumberg:  Kevin Blumberg, The Wire. Today's a
special day, Cathy.  
              Cathy Aronson:  It is. 
              Kevin Blumberg:  It is.  50th anniversary of RFC.  50
years ago today.  April 8th.  
              Cathy Aronson:  Written by... 
              Kevin Blumberg:  Stephen Crocker.  Whether it's the 7th or
8th, I defer.  So to another 50 years to all of the rest of us in the
room.  
              Cathy Aronson:  I know, right.  
              (Applause.) 
              Michael Casadevall:  This might be a slightly touchy
subject, but has there been any discussions on possibly opening up the
last remaining blocks of IPv4, the Class E space, for future transition
five to ten years down the line?  
              Cathy Aronson:  No.  Because -- well, there have been
discussions.  But the thing is that the amount of time it would buy us
pitched against the amount of engineering and host changes it would
take, it's just not worth it.  I mean, that's basically -- 
              Robert Seastrom:  What Cathy said, we discussed that even
for private space 10 years ago, and it got no traction because too much
effort. 
              John Curran:  Right.  There's been at least two Internet
drafts that talk about that that were discussed in the IETF, both of
which were panned by that community.  
              There have been drafts suggesting that to the IETF; both
were panned in the IETF community.  
              Michael Casadevall:   Thank you for that answer.  
              Cathy Aronson:  Anybody else, or was that just everybody
got everybody to the microphone?  All right.  Thanks, everybody.  
              (Applause.) 
              John Curran:  Thank you.  Okay.  We're going to have a
brief break outside.  Everyone's going to get a chance to do a little
stretching of their legs, relaxation, refreshments.  
              We're going to come back in here promptly at 11:00 because
we have two Recommended Draft Policies to consider.  So I look forward
-- everyone enjoy your break, and I'll see you at 11:00, 30 minutes from
now.  Thank you.  
              [[Break.]]
              John Curran:  Welcome back, everyone.  If folks will come
in and be seated.  So I wear glasses.  These are not my glasses.  These
are someone else's glasses that were left.  If you need a pair of
glasses and you think these are yours, come find me.  
              Okay.  We have the policy block starting.  And I want to
-- do we have announcements?  No, going right in.  Very good.  
              So I want to start right in with Recommended Draft Policy
2018-2: Clarification to ISP Initial Assignment Size.  And this is a
Recommended Draft Policy.  So I'm going to give you the formal review of
its history to date.  
              This could be adopted after this meeting.  The Advisory
Council could recommend it for adoption to the Board of Trustees.  
              This started as ARIN Policy Proposal 252 and became Draft
Policy in March of last year.  It was revised in June.  It was
recommended in November of 2018 and revised subsequently.  It's been
presented at two prior ARIN meetings.  
              The staff understanding, 2018-2 provides criteria that
organizations without direct assignments for allocations must meet in
order to receive an initial amount of IPv4 space.  
              It states very clearly that all ISP organizations without
direct allocations, direct assignments, reallocations or reassignments
will automatically qualify for a /24 of IPv4 space.  
              They can qualify for more than that, but then they need to
provide documentation, which would be up to a 24-month supply.  It
provides guidance for ISPs that hold reallocations or assignments
stating they must show efficient utilization for those requirements
consistent with 4.2.3 and 4.2.4, a very straightforward change and will
make the processing fairly simple.  
              We'll be able to implement that, and ISPs can get a larger
block as described in the policy.  So organizations that currently have
resources will need to show the utilization.  No difficulty there.  
              There's no legal material issues with this proposal.  
              Resource impact.  Minimal impact.  It could be implemented
three months after its ratification by the ARIN Board.  We would update
the guidelines, staff training, and there would be nominal engineering
work.  
              So I'm now going to call up Kerrie Richards to give the AC
presentation.
RDP ARIN-2018-2: CLARIFICATION TO ISP INITIAL ALLOCATION 
              Kerrie Richards:  Good morning, everyone.  
              All:  Good morning.  
              Kerrie Richards:  Good morning. 
              All:  Good morning.  
              Kerrie Richards:  All right.  So the problem statement. 
As discussed in more detail in 2017-9 and in the previous Policy
Experience Report, the criteria to qualify for an initial block of space
in 4.2.2 and 8.5.4 are seemingly at odds.  
              This policy has been around since last March.  We think
that we've sufficiently ventilated it.  We've sent it to staff and
legal.  We have implemented all of the changes that were suggested. 
              So the policy statement is to replace the current Section
4.2.2 with all ISP organizations without direct allocations, direct
assignments, reallocations or reassignments automatically qualify for a
/24.  
              These organizations are exempt from the requirements of
showing utilization in previously held IPv4 space as we spoke about
earlier.  
              So the progress since ARIN 42.  In October we did the
staff and legal.  That was complete.  Changes were made January to March
of this year.  It was sent to PPML.  Not much comments.  And it is our
intention that we will put it to the community for Last Call after this
meeting.  
              At this time -- 
              Paul Andersen:  Thank you.  Good timing, too.  My laptop
randomly rebooted and decided to do a 30-minute update.  
              So, the microphones are now open for anybody in the room
to come and discuss this Policy Proposal either here in the room, or if
you're online, we have someone in the room eagerly waiting to read your
comments into the record. 
              Again, this is a Recommended Draft Policy.  So even though
I know the printed guide is not in distribution as much, somewhere on
the website you'll see there's this lovely flow chart.  So if you're not
familiar with the policy process, it gives a great breakdown of how a
proposal gets there.  
              As I mentioned, this is the last time you may see it
before it gets adopted.  So it's very important, if you're in favor,
against, to come to the mic and speak on that.  
              Not all at once, though, because we don't want anyone to
get hurt trampling to the microphones.  Please.  Going once -- it's very
important input to the Advisory Council.  
              Front microphone, please, and please make sure to speak
your name and affiliation.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. Can you bring
up the policy text?  And I guess the first thing is I'm neither for or
against the policy at this time.  
              There was a little bit of confusion between the staff or
the slides in that this says organizations without anything
automatically qualify for a /24 -- that's what's on this page -- without
direct allocations, assignments, et cetera.  
              But on the other page it said that these organizations are
exempt from the requirements of showing the efficient... 
              In the staff -- can you go to the staff one, please? 
Backwards, yeah.  
              Paul Andersen:  I don't know if we can go to that one. 
Can we switch back to the staff report?  Sorry.  One moment.  
              Kevin Blumberg:  It sort of contradicted that.  It said
that organizations that do not have direct allocations, et cetera, et
cetera.  So staff are saying -- or what it appeared to me to be was one
was saying that an organization that doesn't have anything can qualify,
and the policy seems to say you're exempt if you've got all of these
things.  
              And I didn't understand why there was that differential.  
              Paul Andersen:  We're just rereading as you raised this. 
              John Curran:  Kevin, which is the -- do you believe that
the staff analysis is incorrect of the offered text?  
              Kevin Blumberg:  I wanted to bring it up so I could
double-check. 
              Paul Andersen:  He's trying to understand the difference. 
              Kevin Blumberg:  Right, right.  
              John Curran:  But you haven't come to a conclusion one way
or the other. 
              Kevin Blumberg:  I haven't.  That's why I was asking.  
              John Curran:  Okay. 
              Paul Andersen:  Normally we wouldn't take -- but since
there's no hoard at the microphone, we'll just kind of ... all right,
there we are.  Is this the one where -- 
              Kevin Blumberg:  So, first of all, they say, "must show
efficient utilization of their current resources."  So that is in
contradiction to the actual policy itself which says you qualify. 
              Paul Andersen:  I think John has his interpretation. 
              John Curran:  So the policy text says:  All ISP
organizations without direct assignments, allocations from ARIN qualify
for an initial allocation up to a 21 depending on ARIN's minimum size.  
              Kevin Blumberg:  That's existing text, correct, the 21?  
              John Curran:  No, that's -- 
              Paul Andersen:  That's the policy statement. 
              Kevin Blumberg:  Policy text, okay. 
              John Curran:  So the staff says -- you're asking about
efficient utilization of current resources.  
              So at the bottom it says "ISPs holding reallocations or
reassignments must show the efficient utilization of their resources
consistent with 4.2.3 and 4.2.4."  
              Paul Andersen:  It seems consistent with that. 
              John Curran:  It seems consistent with that.  
              The third line of the proposed text is "ISPs holding
reallocations or reassignments must show efficient utilization of their
resources."  
              Paul Andersen:  Yeah, the first two paragraphs are those
without one of those criteria.  And the third paragraph is with.  Does
that address your -- 
              Kevin Blumberg:  That addresses my concern. 
              Paul Andersen:  Did you want to comment on the policy,
then?  Sorry, Owen, I know you were coming to clarify.  
              Kevin Blumberg:  My second question to this is:  How does
this affect things like the waitlist?  Overall, I'm in support of this. 
It makes things a lot easier for everybody.  
              But when we are basically creating a situation of
automatic approval in one section, does that then create and pose an
issue for things like the waitlist?  
              Paul Andersen:  The waitlist is suspended.  So it
effectively is as if there's not one right now.  So... 
              Kevin Blumberg:  It is a generic question in that when
things are automatically approved and if the waitlist was not suspended
or there was a new waitlist, or whatever the case may be -- I know
there's a number of other policy proposals -- but does this proposal
create -- and maybe it's for the other policies to know that if this
policy moves forward, then there could be a -- 
              Paul Andersen:  Could I suggest -- because I think the
correct is that you would ask the AC to take into consideration as it
looks at the waitlist proposal that's been suspended, that it consider
how this would impact it. 
              Kevin Blumberg:  Right.  Correct.  
              John Curran:  Kevin, how would you like this to affect the
waitlist?  
              Kevin Blumberg:  I do not want this to affect the
waitlist.  I don't think that anything that is automatic like that
necessarily feeds into it.  But it's more I want an understanding that
this would affect potentially things like -- because it would allow for
/24s -- would this affect 4.10 as an example?  Or does 4.10 sort of have
its own things?  
              So if the AC can consider that, does it have impacts to
other policies by this automatic approval, but overall I am in support
of it. 
              Paul Andersen:  You are in support.  Thank you for that
feedback.  Front microphone.  
              Alison Wood:  This is my own.  Alison Wood, state of
Oregon and on the ARIN Advisory Council.  When you've been working on
this, and to piggyback off where Kevin was going, have you gotten a read
on how many ISPs are going to take advantage of this policy or what the
general community need is?  
              Are we going to get just a flood of ISPs coming in asking
for a /24, or is this going to be kind of a onesie-twosie thing where we
are making it easier for the community but we don't have a tremendous
amount of ISPs that are needing space right now.  
              Paul Andersen:  I think John Sweeting would probably have
the best answer.  
              John Sweeting:  John Sweeting with ARIN.  This is initial.
 So ISPs that are there -- this is for a new ISP that is starting out
that has no IP space.  They can initially qualify for a /24 by the basis
that they are an ISP that it wants to provide service.  
              So it's just the initial.  So the effect -- yeah, it would
affect the waitlist.  But it's just the initial. 
              Alison Wood:   Have you had a lot of people coming in
wanting -- 
              Paul Andersen:  Do we have data on the number of initials
that -- 
              John Sweeting:  I don't have it off the top of my head,
but I can get it.  
              Paul Andersen:  Okay.  
              Andrew Dul:  Andrew Dul, ARIN AC.  I'd like to remind the
group that the genesis of this policy is to fix a discrepancy between
the transfer policy and effectively the waitlist policy wherein there
are two different requirements for an initial ISP if you -- depending on
if you pull the transfer button first or if you pull the waitlist button
first.  
              And the goal of this is to harmonize it so it doesn't
matter if you apply under Section 4, the previous waitlist policy, or if
you went to go get approved for a transfer, the rules would be the same.
 That's the goal of this, to make it the same for transfers and for
waitlist or whatever. 
              Paul Andersen:  Are you in favor or opposed?  
              Andrew Dul:  I'm in favor of the policy as written. 
              Paul Andersen:  Front microphone again.  This time holding
a device.  
              Alison Wood:  Remote participant, Brian Jones.  He wanted
to state that he supports 2018-2 as written.  
              Paul Andersen:  Thank you, Brian Jones.  
              I have depleted my source of speakers.  So I would ask if
you are online to start typing feverishly, or if you're in the room and
want to be able to have comments, to approach a microphone quickly.  
              After I close the microphones shortly, we will then go to
a poll, a show of hands on those that support and those that are
against.  We'll be closing the microphones at the end of this next
comment.  
              Alison Wood:  Jeremy Austin also states that he supports
the policy.  
              Paul Andersen:  Thank you to that remote participant.  
              With that -- I'll give the remote participants...is there
anything else being typed?  
              Alison Wood:  No. 
              Paul Andersen:  With that, we'll close the microphones. 
We'll thank the AC for its presentation.  
              (Applause.) 
              This is audience participation time.  If you are watching
this either in the room or online, you are entitled to show your support
or show that you are not in support of this policy.  
              So I'm going to ask -- I'll tell the question first.  I'll
ask those in favor of advancing the policy as written, I'll ask for
those in favor and those against.  
              If you are in the room, please raise your hand and keep it
raised until I ask you to put it down because our expert counters, who I
think are in position, need to count.  
              On the matter of 2018-2, all those in favor of advancing
the proposal as written, please raise your hand nice and high and keep
it there.  One hand only, please.  Give it a second.  
              I can't tell who is voting because, as you've already
heard, there's 17 blinding lights.  I kind of see some hands in the
front.  I need my counter to give a very obvious sign when we're ready. 

              Please keep it up.  Thank you.  You can put your hands
down.  
              And now all those opposed to the proposal as written,
please raise your hand if you're in the room.  Of course, remote
participants need to follow the steps that are sitting on the screen
beside us.  Somewhere right here, I believe.  Just waiting for the
results.  
              Tonight is social night.  After a full day of policy,
we'll go to our always entertaining and enjoyable social.  So details to
come soon.  I see the envelope on its way down.  
              On the matter of 2018-2, we have 108 people participating
in the room and remote.  In favor, 40.  Against, zilch.  This will be
provided to the AC for their consideration.  Thank you.  
              John Curran:  We're going to move ahead.  I am still in
possession of a pair of glasses, fine reading implements.  If you're
reading your Discussion Guide and it's blurry, please come to the front.
 
              (Laughter.) 
              Okay.  Thank you.  We're going to move on to the next
Recommended Draft Policy, Recommended Draft Policy ARIN-2017-12: POC
Notification and Validation Upon Reassignment or Reallocation.  
              Because it's Recommended Draft Policy, I'll do the
introduction.  
              This started as ARIN Policy Proposal 247 in October of
2017; became a Draft Policy in November; became a Recommended Draft
Policy last March.  
              It went to Last Call, and it was recommended to the Board
for adoption and the Board sent it back.  We don't do this very often. 
But we remanded it to the AC last August.  
              And the reasoning behind that was effectively that it
was -- the way it was originally phrased it was a significant burden
both to ARIN and to the parties involved.  And we wanted to make sure
that the AC was clear of that intent.  
              The AC revised it last month.  And so this policy in
various forms have been presented at ARIN 41 and 42.  
              Staff understanding -- that's interesting.  It was revised
in March.  And the Staff and Legal Review was 28 February.  Have we had
a Staff and Legal Review since the revised text?  
              Owen DeLong:   (Indiscernible.) 
              John Curran:  It was revised in February.  Okay.  I knew
that was the case because I'm never supposed to be here talking about a
recommended policy that doesn't have a staff and legal.  
              It was revised recommended in February -- 25, I'll bet,
and we're going to confirm that.  
              This is the Staff and Legal Review that occurred
afterwards.  Owen.  
              Owen DeLong:  It was revised in February, recommended in
March.  
              John Curran:  Thank you.  Okay.  Wonderful.  So, yes, it
was revised.  We did a Staff and Legal Review.  And the AC recommended
it in March.  Okay.  So everything is in order and we're just
double-checking things here.  
              Okay.  So staff understanding from the revised text is
that NRPM Section 3.7 requires all requests for reallocation or detailed
reassignments can only be made to existing organizations at least one
validated POC object.  
              This is a large change to how we do business.  Several
customers have automated their reallocation/reassignment process with
ARIN following the current model.  
              These changes will add some complexity and possible
additional states to automated systems interacting with ARIN.  These
changes will require customers requesting reallocation of detailed
reassignments to gather and verify information prior to submitting their
requests. 
              These changes will provide a higher privacy protection to
the organizations that are having reallocation/reassignments submitted
on their behalf.  ARIN would be required to notify all POCs requiring
validation through email notification, whether the request was
successful or not.  
              So this will improve the accuracy of the data in the ARIN
database.  It will not have a direct effect on RSD operations because,
as the policy's been changed, they're automated.  There could be some
increased support tickets as a result.  
              We can implement this policy as written.  There's no
material legal risk to this policy.  
              There's a pretty sizable resource impact, because we need
to change the systems, particularly the ones that are used automatically
by developers to submit reallocations and reassignments to do the
necessary checking.  Could be implemented with about eight weeks of
development work.  
              It will take approximately six months to accomplish that
in our current schedule, once ratified by the Board of Trustees.  
              So I'm now going to have Chris Tacit come up and give the
ARIN Advisory Council presentation.  
RECOMMENDED DRAFT POLICY ARIN-2017-12: POC NOTIFICATION AND VALIDATION
UPON REASSIGNMENT OR REALLOCATION 
              Chris Tacit:  Thank you very much, John.  Before I start
the clarification about the timing of things, it was moved to
Recommended after the staff and legal, but the staff and legal itself
recommended a very minor wording change.  
              So there was a further change made to it after that, but
that change is not material and doesn't affect the Staff and Legal
Review because it was based on the recommendation in the Staff and Legal
Review.  
              All right.  So here's the problem statement.  I'm not
going to read it.  But basically the problem in a nutshell was that with
these automated reassignments, you could end up with POCs being created
relating to individuals who had no idea that they had POCs or even
understood what ARIN is, and it created a lot of spam for them
potentially if there were multiple POCs associated with their email
addresses and also created issues around POC validation.  
              So the Policy Proposal obviously wants to fix that
particular situation, and essentially it does so in a much more elegant
manner that actually my co-shepherd, David Farmer, came up with than the
previous original text.  And it basically does so by ensuring that
there's at least one valid POC object available before any such
reassignment is linked to it.  
              And then once that happens, there's a communication
element to this where all the POCs associated with the same Org are
notified, and there's a request to validate any POC objects that have
not been validated.  
              So John already went over the staff and legal.  So I won't
belabor that.  And the relevant history here is that, as I said, David's
rework and then our joint effort to finalize that wording we think is a
much simpler way to implement this than the original text and obviously
a lot cheaper and less intense for ARIN than the original proposal was. 

              There's been very little said on PPML about this one way
or the other since the language was revised more significantly.  We
think that probably means there is community support.  But we would like
to validate that today and ensure that such support does persist. 
              The reason we think that is because people were not shy
about weighing in and objecting to the original language.  And the fact
that things are so quiet now suggests to us that there is support.  But
we obviously want to make sure that persists before going ahead and
taking this to Last Call.  
              The other thing we want to make sure is that from an
operational perspective, because there will still be some burden on
those interacting with ARIN to implement this in their own automated
systems, that they're not going to be tempted not to record
reassignments and reallocations, which would obviously result in a less
accurate registry.  We don't want this to have a perverse and unintended
consequence. 
              So those are a couple of the things that we'd like you
folks to consider and comment on.  
              Paul Andersen:  So no news is sometimes good news, but the
AC does appreciate feedback even if it is just to state that you are in
support.  So hopefully we can fix the trend here from PPML.  
              So those that would like to speak in favor, against this
revised policy that's been taking a long and windy road, please approach
a microphone.  Yes, the long and windy road.  Gotta pay extra for that. 

              Front microphone, please.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I want
to speak in support of this policy because having up-to-date and
accurate POC information is incredibly valuable when dealing with
network DDoS attacks or bad traffic of determining who owns a block, who
to contact and being able to help mitigate issues from point to point. 
So the Whois is incredibly valuable, and more accuracy goes a long way. 
So... 
              Paul Andersen:  Thank you for that support.  
              Others who would like to speak, please approach a
microphone.  
              Front microphone.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. I'm in support
of the proposal in principle, but I have two hesitations.  
              Staff and legal came back, and it's still very, very --
has a high cost and a high-implementation scenario.  And I'm concerned
that really we've tweaked the wheels and it's going to go back to the
Board and it's going to get remanded again back, because I don't really
see a substantive, substantive change to what is fundamentally the issue
of automation.  So that was my first part.  
              And, John, if you want to -- 
              Paul Andersen:  I'm actually going to address it.  It
wasn't sent back by the Board because it was too expensive.  That was
not -- there were concerns also just about the deployment and whether
the operator community had fully engaged, because sometimes we've had
policies where they weren't engaged.  
              To take a substantive effort, which is something we're not
opposed to if the community wants when we weren't sure it was flushed
out, would not be a good use.  But because now the AC has taken
extraordinary steps to flush that out, I don't think the -- I can't
speak what the final, but the eight weeks does not -- we've had policies
that have been higher implementation costs. 
              Kevin Blumberg:  I wasn't referring to expense in terms of
dollar figure.  I was referring to expense in terms of the cost to the
community to fix their automation, costs to ARIN to fix its -- it's an
overall -- the human hours, the people hours, the concerns there.  
              So that's what I meant by "expense."  If that has been
significantly lowered -- 
              Paul Andersen:  I think the AC will have to evaluate and
the Board when it gets referred.  
              Chris Tacit:  Just so you know, in terms of the sort of
extraordinary consultation that we did undertake after it was remanded
to us, we actually went out to the operator community and we held
sessions during the last NANOG to try and get input from operators as
well on what would be acceptable to them and so on.  So this is largely
a product of that effort.  
              Paul Andersen:  Thank you, Chris.  
              John. 
              John Curran:  As Paul -- I don't know what the full Board
will do with this, but recognize that the original proposal, it wasn't
clear that that engagement had happened, and now it's clear it has.  
              Additionally, there's nothing wrong with us doing
development work for what the community wants.  That's why we're here. 
We do it all the time.  
              The original proposal had a creative/innovative process
for addressing organizations that couldn't be added and needed to be
remanded that involved tickets and RSD team.  
              This process is a lot more straightforward.  The
combination of the outreach plus a straightforward process means this is
a very different -- even though it's still a lot of coding, it's a very
different impact overall.  
              Doesn't change the impact to the community who has to work
with it.  Doesn't change the impact or the fact that there's coding that
has to be done, but a lot of the aspects of this have been resolved. 
              Paul Andersen:  Another comment, Kevin?  
              Kevin Blumberg:  In answer to Chris's question, I believe
that this will lower the amount of detailed assignments.  People will
move to simple when there's that chance.  From an automation
perspective, it makes no sense to do this when you can go to simple, and
they will make that determination obviously on their own company.  
              So I do see us moving more towards simple.  We should have
been there in the first place.  
              I absolutely support this because I'm tired of seeing my
name or other people's names showing up on records when they shouldn't
have in the first place.  So this is addressing the real issue, which is
that individuals don't have a way of getting themselves off of it.  They
need to be validated in the first place.  
              But this is not going to improve, as was brought up
earlier, accuracy because we're going to see simple assignments without
any information, which I think is actually more appropriate in this case
because what you would have gotten is bogus information as well.  Thank
you. 
              Paul Andersen:  Thank you for that comment in support.  
              Front microphone still.  
              David Farmer:  David Farmer, University of Minnesota, ARIN
AC.  
              I would like to invite any ISPs that are making large
amounts of detailed records to come up to the mic and please inform the
community what you might do.  
              I'm not going to name names because that's not
appropriate.  
              Paul Andersen:  Please do not name names. 
              David Farmer:  Yes.  But, please, if you're in the room or
online, please make some comments.  It is important that you do this.  
              Paul Andersen:  Alternatively, also feel free to catch at
lunch -- the AC is around all week.  
              Front microphone.  
              Please approach a microphone if you wish to speak, because
we'll have to close as we're getting to depleting speakers.  
              Alison Wood:  I have three.  I may need those glasses.  
              Brian Jones:  My organization does not currently use
automated reassignment methods.  With that said, I support the policy as
written.  Valid contact information is very valuable to the community at
large.  
              Then I have Jason Schiller, Google, ASO AC:  Can we
clarify if ARIN will notify via email all POCs associated with the
receiving organization includes, possibly optional, all emails of ARIN
Online accounts linked to the Org ID?  
              Jason also says he supports it as written and he would
prefer greater support of unwitting POCs to set things straight, but
this is much better than our current situation with where these are
discovered during annual resource review.  
              Paul Andersen:  John, the question there from Jason there,
does staff interpret that text that you would email -- would you email
all contacts on ARIN Online?  Could you read his question one more time?
 
              John Curran:  All the contacts associated with the
organization.  That's not the same as all the accounts.  That's a
different thing.  
              Alison Wood:  Right.  He says:  Can we clarify if ARIN
will also notify via email all POCs associated with the receiving
organizations including all emails of ARIN Online accounts linked to the
Org ID?  
              John Curran:  If you have an ARIN Online account, which is
tied to a POC, which is part of the organization, then the POC will get
notified, and so you'll get that notification.  
              It is possible, if you have an ARIN Online account that's
not a POC and you wouldn't get notified, only notifying the POCs on the
organization record. 
              Paul Andersen:  Jason, let us know if that addresses your
question.  
              You said there's one more. 
              Alison Wood:  One more, Dawn Bedard, Microsoft:  The
challenge of the ISPs creating POCs automatically is a problem.  I spend
a lot of time where I get emails internally when this happens, and we
ask them to tell the ISPs what the correct contact information is.  
              We have worked very hard and are still working on
standardizing POC information with RIRs.  I support the proposal but am
concerned that the implementation will not happen.  
              Paul Andersen:  Okay.  Did you want to address -- 
              Chris Tacit:  So when they say implementation will not
happen, will not happen by whom, I guess, is the question?  At their
end?  Is -- 
              Alison Wood:  I don't know.  As soon as Dawn responds,
I'll come back to the microphone.  
              Paul Andersen:  We'll close the microphones at the end of
this comment, with the exception if the two remote participants want to
address the questions we proposed, we'll take those.  But please
approach a microphone quickly because we'll close the end of this
comment.  
              Jeff Anderson:   Jeff Anderson, Implex.Net.  I support
this as written.  I think anything we can do as a community to increase
the accuracy of our dataset, we should do.  We realize there's an impact
to implement this, but I think it's worth doing. 
              Alison Wood:  Dawn responded.  She said, "By the ISP." 
              Paul Andersen:  Did Jason indicate he wanted to -- 
              Alison Wood:  No response. 
              Paul Andersen:  If somebody does want to ask questions,
you can get them during the lunch break.  Thank you so much for the AC
and their presentation, Chris.  
              (Applause.) 
              My expert pollers are in position.  We'll ask the same
style question as the last one, as this is a Recommended Draft Policy.  
              First those in favor of 2017-12 advancing as written and
those that are opposed.  If you're remotely participating, please show
your indication now.  
              If you're in the room, all those in favor of 2017-12
advancing as written, please raise your hand nice and high.  
              Thank you.  You can lower it.  And those opposed to
2017-12 as written, please raise your hand nice and high.  
              That's an opposed hand?  
              Chris Tacit:  No. 
              Paul Andersen:  I was confused.  I'm glad I asked. 
Pollers, did we get that?  Just a moment, and we'll wait for the
results.  
              Are we getting an early lunch or announcements -- we might
get an early lunch, I think, after very important announcements.  
              All right.  Thank you for your patience.  Thank you, sir. 
On the matter of 2017-12, total participants in room and remote is 113. 
In favor, 41.  Against, one.  This will be provided to the AC.  And this
concludes our policy block.  
              John has announcements.  
              John Curran:  Okay.  That concludes our morning sessions,
and we are going to have lunch right after this.  Two quick
announcements.  
              First, at the lunch, there's lunch table topics.  If you
want to talk about a particular topic, walk around the lunch area,
you'll see these little signs.  
              That table, people interested in that topic should
converge on those tables.  And certainly these topics are interesting. 
So I recommend you take a look:  Whois database cleanup, IPv4 Waiting
List.  Transfer policy is always popular.  PPML participation and
training at ARIN.  And joining the AC.  That's a good table.  
              RSD Help Desk is open and out there and available.  Good
time to come by and work on anything you might have with Registration
Services.  It will be opened during CaribNOG for the rest of the week.  
              Security.  The room is not locked.  Take your valuables
with you.  We're going to be back here at 1:30.  We're going to consider
third-party organization record creation and reassignment requirements. 
We have two policy blocks, two policies to consider, Recommended Draft
Policies.  
              We will start promptly at 1:30.  Okay.  At that, enjoy
your lunch.  They'll be setting up in about five, ten minutes outside. 
So just want to let you know.  Five, ten minutes before lunch is ready. 
But you're free to take your stuff and look at the beach.  
              [[Lunch recess taken at 11:40]  1:30.] 
              John Curran:  If folks will come in and be seated, we'll
get started.  
              We'll start with the announcements.  So this afternoon's
agenda.  We have one Recommended Draft Policy, ARIN-2018-5: Disallow
Third-party Organization Record Creation.  
              We have a number of draft proposals:  2018-6: Clarifying
Reassignment Requirements; 2019-1: Clarifying Section 4 IPv4 Request
Requirements; 2019-3: Updating Section 4.10 for IPv6 Deployment Block
Assignments.  
              We have a presentation on our website and routing registry
update.  We have a presentation of a report that was done, a study on
IPv6 economic factors for deployment.  And then we'll have a discussion
of community input on future meeting agendas.  And that should be this
afternoon.  Should be a good day.  
              We are going to start right in.  At the head table, we
have the same people.  We have Paul, our chair of the Board; Bill, our
vice chair; Tina, chair of the ARIN Advisory Council; Leif, vice chair
of the ARIN Advisory Council.  
              (Applause.) 
              Applause because that might be the first time in 20 years
I've gotten it right from one end to the other.  
              So there's someone out there feeling their way around the
Hilton.  If you see them, bring them to me.  Their glasses are still
here.  They were left at the back of the room at the first break.  
              Okay, so let me start right in on the Recommended Draft
Policy.  
              Recommended Draft Policy ARIN-2018-5: Disallow Third-party
Record Creation.  This was a Policy Proposal in October of 2018.  They
adopted it the following month as a Draft Policy.  
              So draft policies -- let me talk about that.  Proposals
are things that you guys have an idea.  You send us a proposal.  It
defines a problem.  Might suggest some text.  
              When the AC says, "Yeah, that is an actual understandable
problem," they may not agree with your problem, but they understand it's
something to do with the Number Resource Manual and it has a fairly
cohesive statement of what you're trying to fix, then they'll adopt it. 
And it becomes a Draft Policy.  
              At that point it's under ARIN Advisory Council control,
and they watch the postings on the Mailing List and they take input from
everyone and use that to revise it based on community feedback. 
              This became a Draft Policy in November.  Based on
feedback, it was revised a few times, ended up the last revision was
February 4th of this year.  
              It was recommended for adoption in 2016 -- I'm sorry, 26th
of March 2019.  So that means that the AC has found it meets the
criteria necessary for a good policy.  
              That means that it has a clear problem.  It has a -- it's
technically sound.  It is something that is supportable, supported by
the community.  
              They're going to confirm that at this meeting.  So that's
why we're going through this.  So this is the first time being
presented.  If it has support from the community at this meeting, it
could actually -- as a Recommended Draft Policy, it could be sent to the
Board to be ratified and put in the Number Resource Policy Manual.  
              So Staff and Legal Review.  2018-5 requires that only an
authorized contact that is verified by ARIN be allowed to create a new
organization record.  The request must be submitted directly to ARIN by
the organized contact and no third-parties shall be allowed to create
organization records on behalf of the new organization.  
              This means that organizations wishing to
reallocate/reassign address space to their customers must coordinate
with the customer to ensure they have created an Org ID first.  We'll
need to ensure that no matter which method is used to reallocate/assign,
the Org ID will be verified prior to creation.  
              It will have an impact on registration services as there
will be more organizations created; therefore, more questions, more
tickets.  
              These changes will result in more accurate information. 
The development for system changes, about four weeks.  It can be
implemented as written.  There's no material risk to this policy.  
              Resource impact.  Medium resource.  It can be implemented
probably three months after ratification by the ARIN Board.  It changes
the guidelines, procedures, documentation on the website.  There's an
additional workload to RSD for processing Org create tickets that we
anticipate.  Medium level of engineering effort is required.  
              So that concludes my introduction to it.  I'll now have
Andrew come up and give the ARIN AC presentation.  
RDP ARIN-2018-5: DISALLOW THIRD-PARTY ORGANIZATION RECORD CREATION 
              Andrew Dul:  Good afternoon, everyone.  I hope you all had
a good lunch.  Let's jump right into Org IDs.  So, what is an Org ID? 
Is it a strange creature?  Something else?  Maybe this is an Org ID. 
No, this isn't an Org ID.  This is actually a hoary marmot that I found
in Mount Rainier National Park.  
              Let's get on to Org ID.  Organizational record is actually
an Org ID.  It's basically a top-level database record that we have in
the ARIN database that defines an organization.  
              We kind of have a sample one here on the slide:  Bob's
Bait and Sushi, just down the street here on Waterfront Road.  
              And most of the time Org records are referred to by IPv4
and IPv6 blocks, ASNs, and they also have Point of Contact records
associated with them.  
              Okay.  So how do we create an Org ID today?  You can do it
in ARIN Online.  You can still do it via email templates.  There's three
different templates -- actually, there's five different templates you
can do it with:  an Org template; reassign detailed, either v6 or v4; or
a reallocation template; and you can also do it via Reg-RWS, which is
the API instance into the ARIN database.  So there are many different
ways you can create the Org ID today.  
              This is a long problem statement.  I won't read it to you.
 It's also in your packet, for those of you who have it, or on the
website.  
              Basically the premise of the issue is that the way that we
create Org IDs today creates a whole bunch of database cruft.  When
people create reassignment records, they basically often just add an
additional Org record just because it's easier rather than assigning it
to an additional one. 
              And we want to stop that practice so that we have
organization records that actually represent real organizations that
exist in the world.  So, how do we do this?  
              This is the text that is going to be changed.  Basically
adds a little section that says that we're only going to create
organization records from authorized contacts representing that specific
entity.  
              So if you're an ISP, that means that -- and you're going
to reassign a record to someone else, it means that someone else has to
come to ARIN and create an Org record for you to create a reassignment
or reallocation record for that specific organization.  
              What's the effect of this change?  We kind of already
highlighted this a little bit.  The authorized representative has to be
verified by ARIN, and they are the only ones that can read an Org ID. 
And ISPs have to get the organization themselves to start with ARIN
first before a reallocation or reassignment record can be created. 
              So, what of the outcomes that we hope to have from this? 
We hope to reduce the number of Org IDs in the database overall and make
them more accurate because they actually represent records that are
created by organizations rather than alternate records that are created
by ISPs.  
              So the discussion points.  Do you support this policy
change?  And specifically, if you are a large or other ISP that makes a
number of reassignment records or reallocation records, we want to hear
from you on this, just like the POC change that we discussed about
earlier today.  
              This could be a significant impact on your workflow.  And
we want to make sure that we're taking that into account as we make this
change and make sure that we have the correct timeline for
implementation that will meet with many of the organizations around
there, around our region.  
              And do you have any issues or questions about the
implementation or any other suggested changes?  
              One comment about -- that had come up on the list since we
made the slide deck is a clarification to make sure that people who are
acting as contractors for small organizations are able to continue to
make those records. 
              And so any comments about that, what would constitute an
authorized contact, we'd like to hear from you in the room on that
discussion.  So, thank you very much.  
              Paul Andersen:  Thank you, Andrew.  Microphones are open. 
Recommended Draft Policy.  Same drill.  I know food always slows down a
bit.  But I'm sure that somebody will approach the microphone quickly. 
Someone might even want to be Kevin.  His nemesis is approaching the
mic.  Front microphone.  
              Owen DeLong:  Owen DeLong, ARIN AC.  I don't think I'm
Kevin's nemesis.
              (Laughter.) 
              Paul Andersen:  For getting to the mic first.
              Owen DeLong:  He had clear advantage earlier.  I don't
know what he did.  Regarding the Policy Proposal, I support it as
written.  
              I think that this is an important problem to solve.  In my
previous employ, I spent a great deal of time tracking down and
eradicating Org records and POC records and all kinds of other records
that were created on our behalf erroneously by various contractors that
a random person in the company had contracted with and they had just
sort of put information in there that felt good.  
              And this led to much badness.  So this is a definite
needed thing and I hope we will move forward.  Thank you.  
              Paul Andersen:  Thank you.  Next speaker.  
              Louie Lee:  Hi, this is Louie Lee.  This is Louie's hood. 
              Paul Andersen:  Tell us what happened to Louie's hat.  
              (Laughter.)
              Louis Lee:  Find me at the social.  I'm with Google Fiber
and also on the NRO NC.  And in my previous job I was at an IX operator
who operated a small transit service, and in doing so our transit
service is PGP-based and required our customers to obtain an AS number,
many of whom did not have AS numbers previously.  
              I'm telling you all this because it was not that much of a
burden to help them create an Org ID.  It was a matter of walking them
through the application, the form, and let them know, go ahead and come
back to me if they have issues.  If they really needed an Org ID, it's
fairly simple to have even a form that's partially filled with my
information that I need them to have.  
              However, I'm interested to hear from anybody that operates
an ISP that have large numbers of customers who they really want Org IDs
for.  I had only a small number.  But the work per customer was not that
big.  
              Paul Andersen:  But are you in favor or against?  
              Louie Lee:  I'm in favor.  
              John Sweeting:  John Sweeting with ARIN.  I'm neither here
nor there on the policy -- 
              Paul Andersen:  As we would expect.
              John Sweeting:  As would be expected, but I Just want to
say that what Louie just said is very good, but also if there's ISPs
that want their customers to create Org IDs and they don't want to spend
the time with them, there's a help desk number that they can call and we
will walk them through it.  
              We can, as of now even, generate the tickets for them and
give it to them to resubmit to us.  So that's all there and good.  
              Paul Andersen:  Thank you.  Next speaker, please.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. On the online
stuff and the manual processing and the using the help desk, this is all
easy-peasy stuff, and I absolutely support it.  
              But if you look at this morning and the impact to the API,
this would to me completely destroy the use of the API for creating Org
IDs because you'd have to have an Org ID created in the first place.  
              I don't understand the severity of the impact.  And that
wasn't really determined here by staff.  What is the severity of the
impact to the API?  Because ultimately that's the group that's going to
have the biggest issue if this policy, to my mind, is implemented.  
              So what is the scenario in terms of the breakage when this
is now disallowed through the API?  
              Paul Andersen:  It's a good question because obviously
automation might be tricky, but Andrew says he can... 
              Andrew Dul:  So, I think what would happen -- and I think
there's also a question for staff on how the implementation would
work -- but my suggestion is is that create from a Reg-RWS would no
longer be permitted inside that system.  
              I would still expect that modify and delete would be
available because there are other fields that you might want to change
without directly interacting with ARIN via a ticket.  But if there are
other folks who use that Reg-RWS more than I do, that would be good
information to know. 
              Paul Andersen:  John. 
              John Curran:  Create is not a very popular call today
because it requires work to process in any case.  
              You're talking about a circumstance where organizations
that we have right now end up with Orgs created indirectly.  And that's
a different creature.  
              Your question is, how does the API change.  Unlikely the
API will change.  It's just more likely you're going to end up with a
ticket that has to be manually covered in order to provide the
documentation to confirm you're an authorized contact.  And I don't
expect a lot of the automatic people will bother to do that.  Because
they don't have the documentation and they're not the valid contact,
eventually the request will be closed out.  
              So you're trying to distinguish two different things.  If
you want to know about the API, we'll look at what happens to the API. 
It's quite likely it will become very rarely used.  It doesn't mean you
delete it; it means it becomes very rarely used.  
              The different question is what about organizations right
now who want to create Orgs on behalf of their detailed reassignments? 
They can't.  And that impact is the same whether they're using the
RESTful interfaces or not. 
              Paul Andersen:  You're saying, John, that currently the
create API would be automatic under this?  It would now go for manual
processing?  
              John Curran:  It would require a verification of an
authorized contact, which means it's going to be manual. 
              Kevin Blumberg:  So the flip side to this policy -- and,
again, I'm in support of it -- but the flip side to the policy is that
in preventing erroneous records, we are more than likely going to
prevent legitimate records because it becomes complex, and therefore
Orgs are just going to turn it off.  Would that be a fair statement?  
              John Curran:  If you believe that the records that have
been created historically are authorized -- historically they've all
been "authorized," even though they're created by another Org, then
you'll be losing those authorized records that would have been created,
yes.  
              If you believe that most of the records that have been
created are not authorized by the organization they're being created on
your behalf, then that's what you're losing.  You're going to lose a mix
of -- you're going to lose Org records that would have been
automatically created.
              The question is how many of those that were being created
would have actually been qualified by the Org that they were created on
behalf of.  It's a very, very, very, very small number.  
              Paul Andersen:  Does that address your question, Kevin?  
              Kevin Blumberg:  I would use "accurate" versus
"authorized" because if the record is accurate, I really don't care;
it's accurate.  That's all I care about as an end user.  But I don't
think that's the case right now, and I think this is why the policy is
there, is because most of the stuff is not accurate.  It's wrongly
placed.  And the people that should have had a say, the authorized
people in the first place, didn't get a say. 
              John Curran:  And if it is accurate, it's a transient
event that changes over time to become less accurate nevermore. 
              Paul Andersen:  I think we're getting into the rabbit hole
-- 
              Kevin Blumberg:  Thank you, that answers my question. 
              Paul Andersen:  That's an identified question that the AC
should probably at least address and work out with staff.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I'm
tentatively supportive of this policy as written, but I have concerns
for companies that manage other companies' properties.  For example, it
is not uncommon for one company to completely manage all aspects of
another customer's networks IP allocations, so forth and so on.  
              And this would create a -- this currently can be an
entirely transparent process since organization one can create and
manage all the resources for organization two.  
              This would add some burden to that, and while it may be
relatively straightforward to create an Org ID, it may adversely impact
those that act as a middleware for clients, especially those that are
grabbing a bunch of IP blocks and releasing them because of demand
scaling up and down.  So I have tentative -- I have concerns about this.
 
              Paul Andersen:  Luckily the person behind you I think has
experience in that.  So I think he may have some feedback on that.  
              Owen DeLong:  Owen DeLong, independent contractor and
member of the ARIN AC.  Yeah, I've done a lot of the kind of contract
work he's talking about.  And I've got a lot of clients as well.  
              And we discussed this actually on the Mailing List.  It
was pointed out by ARIN staff that, as written, the policy would be
implemented such that if you are able to create the Org ID with the
proper documentation showing that the Org in question has authorized you
to do that on their behalf, you're fine.  
              So you're going to need some form of documentation from
your client that says, yeah, this guy's authorized to interact with ARIN
on our behalf, but that should not be hard to obtain if you're
legitimately operating with ARIN on their behalf.  
              So I think it's actually a solved problem.  I don't think
that there's a need for changes to the policy text or acrobatics to
address it.  
              Paul Andersen:  The LOA returns.  Front microphone.  
              John Sweeting:  John Sweeting, ARIN again.  As Owen can
attest, and anybody else that has created Org's for other organizations,
we have worked with them.  It's the current process.  It's the way we do
business today.  There's really no change needed for that or required.  
              We will verify that the organization has authorized him to
do this for them and that he's able to do it.  And if he wants to be put
on that record as a POC and they authorize it, he's put on the record as
a POC and manages their record. 
              Paul Andersen:  All right.  We still have time in our slot
for more speakers.  However, we seem to have lost.  Would anyone like to
make a comment?  Otherwise, we'll close the microphones.  
              Joe, anyone on the remote typing?  Maybe.  Closing the
microphones in three, two, one.  The microphones are closed.  
              Please thank Andrew Dul, who is running away, for his
presentation.  
              (Applause.) 
              This is a Recommended Draft Policy, as the former two
before it.  So we'll ask now the question of support.  Counters in
position.  Excellent.  
              Those remote, please indicate whether or not you're in
support of 2018-5 proceeding as written or against.  And those in the
room, if you are in favor, please raise your hand now nice and high.  I
know, after lunch, it's tired.  Beach is not far.  
              Oh, I see a wavering hand in the middle there.  Excellent.
 Thank you.  Please lower your hands.  
              And those that are opposed to the policy as written
proceeding, please raise your hand nice and high.  Thank you.  
              As a reminder, if you weren't able to provide input or
didn't want to come up to the microphone, please find one of your trusty
AC members around the event or tonight's social.  Always happy to talk
policy, because who wouldn't?  
              I'm hearing people mocking me in the audience.  
              All right.  On the matter of 2018-5: Disallow Third-Party
Organization Record Creation, the results are:  111 in the room and
remote; 37 in favor; one against.  
              Thank you for this.  We'll move to the next policy.  
              John Curran:  Okay.  Thank you very much.  We're going to
now consider ARIN 2018-6: Clarify Reassignment Requirements in NRPM
4.2.3.7.1.  Alyssa Moore will come up and give the presentation.  
              This is draft policy, so you'll see it again before it
gets recommended.  They're just refining work, and this is a
presentation to help make the policy better.  
              Alyssa Moore:  Hello, everyone.  I am Alyssa Moore.  My
co-shepherd on this one is Alison Wood, world record holder for high
jump.  So ask her about that.  
              (Applause.) 
              So this Policy Proposal is about gaining some clarity
around language of reassignments and what would constitute a simple
reassignment versus a detailed reassignment. 
              And if you are new -- I notice there are a lot of
newcomers in the newcomer session today -- I'm going to make this one
super easy to follow.  So pay attention, and this might be something
that you may have some input on.  
              So we've been throwing around these words:  assignment,
allocation, reassignment and reallocation.  But what do those actually
mean?  It took me a while to figure out when each might be used, and so
I'm going to explain that so everyone is on the same page.  
              So at the beginning of the NRPM there's this definition
section, and it defines what each one of those is.  
              So an allocation is address space that is delegated by an
organization -- or to an organization by ARIN that they can then
sub-allocate to other organizations.  So if you're an ISP, for example,
big ISP and you have downstream customers, you can reallocate address
space to them.  
              Assigned space, if you get an assignment from ARIN, is
space that you are to use as the end user.  You can't reassign or
reallocate that space; you're the end user of that space.  
              So when you make a reallocation, you have to have an
allocation in the first place.  A reallocation can be further
reallocated down the line.  
              A reassignment is space that is sub-delegated that that
organization that it's delegated to is the end user of.  
              So assignments and reassignments, that's the end user.  An
allocation can be further sub-delegated.  
              So, the problem I'm seeing with this one is there's a
section in the NRPM that describes when a reassignment might be used --
sorry, a simple reassignment might be used versus a detailed
reassignment, and there are different informational fields that you have
to fill in for each one.  
              And so what we're seeing is that there are a lot of
organizations who are completing detailed reassignments when a simple
reassignment will suffice.  
              So I'm just going to read through this.  So current NRPM
section reassignment and reallocation information is being interpreted
by some organizations to require a detailed reassignment for all
customers.  Under the current reassignment schema, only a detailed
reassignment or reallocation contains fields for organizational
information.  
              So this policy intends to simplify the reassignment
requirements by noting that only a customer's name is required.  So a
simple reassignment can be used for most cases.  
              So here's the policy statement.  I will leave that up for
a second, but I'm not going to read through that because I have a better
slide coming up that is the redline of this.  
              So there are a couple of changes that are proposed.  So
that's pretty straightforward.  We're just updating it to more generic
language.  So via a directory services system which meets standards set
forth in 3.2 rather than a Whois directory via SWIP.  
              So a SWIP, S-W-I-P, is a Shared Whois Project.  It's a
method of entering information for another organization into the Whois
database.  So Shared Whois Project.  And this is the rest of it.  
              So it would read as:  "Reassignment registrations must
include each customer name, except where specifically exempted by this
policy."  And then all of the red stuff is new.  "Reassignment
registrations shall only include Point of Contact information if either
requested by the customer or the reassigned block is intended to be
routed and announced outside of the provider's network."  
              So two cases where details could be performed.  So if it's
specifically requested or if the customer is going to announce outside
the upstream provider's network.  
              And then finally:  "Reallocation registrations must
contain the customer's organization name and appropriate Point of
Contact information."  
              So that is around reallocations would stay relatively the
same.  
              So this is what it looks like when you go into the back
end of ARIN Online to make a reassignment.  As you can see there, you
can see a simple reassignment or a detailed.  For the purposes of this
use case, we are selecting a simple reassignment.  
              And when you go to the next page there, you can see that
what's required of you is just the name of the customer, the Org name
and their address.  That's a mailing address or physical address.  
              So, so far on the PPML, the Public Policy Mailing List,
there's been a little bit of discussion.  So one was about the intent of
the policy.  And they were asking like is this going to eliminate all of
these fields when you're making reassignment.  That is not the intent of
the policy.  It's just to make it more clear when a detailed versus a
simple reassignment is required.  
              So there were three comments in support, just full
support; one comment in complete opposition; and then two comments that
were proposed changes.  So supported maybe a little bit with proposed
changes.  
              So the comments in support, the crux of that was that a
majority of these organizations' customers with a /29, which is eight
addresses, eight IP addresses, or a shorter reassignment would not
understand what you're even contacting them about.  
              So these are generally smaller, maybe mom-and-pop
businesses or Orgs who have an HVAC system or something that requires,
for whatever reason, an address of their own.  And so they need a net
block of some size.  
              So generally those people aren't going to be able to
respond to emails about abuse or contact about abuse.  So that's why
they were in support.  
              And then the opposition was that the person felt that this
further serves to obscure bad actors by getting rid of information that
might be useful to track down abuse.  
              And then the proposed changes.  So there was one that said
it might be helpful to just adopt the language in Section 6 of the
policy manual but with ranges that were analogous for v4 resources.  
              And there was another proposal to just completely remove
the requirements for reassignments and reallocations where the
delegating entity, so the organization making the reassignment or
reallocation, felt that the customer wasn't able to be responsible for
that block for whatever reason, to just completely get rid of the
requirement to reassign or reallocate.  
              And then there's another proposed change of a schema that
required a name and an email address and a phone number because the
mailing address is not a very efficient way to get in touch with someone
about potential abuse on their network. 
              So a couple of questions to maybe kick off the discussion.
 This is the first time this has been to a meeting.  So this is a step
toward clarity.  Is there support for different contact details of some
kind or anything else that you might want to discuss at the mic?  
              Paul Andersen:  Thank you.  All right, the microphones are
open.  This again is a Draft Policy.  So two things -- my goodness -- as
they all flood the microphones.  Where was that this morning?  
              There's two useful things.  First of all, any feedback on
the policy.  But sometimes it's also useful if we can get feedback:  Is
the problem statement well defined and a problem you think the AC should
be working on, even if you think the solution that they have come up
with is [collapsed] or otherwise?  That is useful feedback at this stage
in their deliberations.  
              And also my apologies to the online stream.  I understand
that we're about two minutes lagged.  So we will try our best to take
that into anticipation as we look for your feedback.  But if you could
also take that into account; that if you have a question, please get it
there early.  
              As somebody has already done, front microphone.  
              Joe Provo:  Proxy for Jason Schiller, Google, ASO AC.  The
proposed text just that an ISP is limited as to when they're allowed to
submit a reassign detail such that if the customer does not ask for
detailed POC info or intends to multihome, the ISP cannot submit
detailed reassignment.  
              I would like the language to be reversed to say an ISP
must submit a reassignment detailed when either requested by the
customer or the reassigned block is intended to be routed and announced
outside of the provider's network.  
              Assuming this is not intended to limit when detailed SWIPs
can be used, I support it. 
              Paul Andersen:  All right, thank you.  Comment taken. 
Next speaker.  
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  I
want to point out one small but potentially significant operational
impact of moving, removing most of the contact information from a
reassignment.  
              There are many companies that incorrectly or incorrectly
use the mailing address in assignment records for geolocation.  
              Removing that will lose that -- will result in
organizations that do that, losing that visibility, leading to less,
potentially less, accurate geolocation attempts.  
              Therefore, I would recommend that if we consider limiting
the number of fields required in a reassignment that we not lose the
mailing address, keep the mailing address in there, possibly, or make it
optional such that the mailing address is not required but is a field
that can be added to the record.  
              I support as written with my recommendation. 
              Paul Andersen:  Thank you for that recommendation in
support.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I
dislike the proposal for several reasons.  The first one is the example
of the [HVAC] system that requires a stack IP and only having customer
name.  
              For someone to have a block of routable IP addresses, they
need to be responsible for it.  And the concept of the customer is not
smart enough to manage it, I don't think that's a valid argument,
because if you're going to have stack IP space, you need to be able to
manage it, or have someone manage it for you on your behalf.  
              In addition, limiting the amount of information about
transfers could both lead to abuse of people's hoarding IP blocks via
shell games and other -- the lack of transparency is extremely
concerning.  
              Having more detailed information about how blocks are
being assigned to individual customers is very important for dealing
with tracking down DDoS, sources, botnets and other information.  
              So moving -- allowing simple transfer, simple reassignment
for these sort of things removes clarity into how ISP networks are
delegating their networks, and the detailed information should be the
standard way to do it, in my personal opinion.  
              Paul Andersen:  I understand you're against the policy
statement, clearly.  Are you also against the problem itself being
solved?  
              Michael Casadevall:  Personally, I'm not sure I see it as
a problem.  If anything, I would completely flip this policy on its head
and require detailed information for all reallocations except for those
that are being directly broadcast and routed by BGP, in which case that
organization has the POC and is responsible for that network because
they're doing the announcement on BGP.  
              Paul Andersen:  Thank you.  If you would like to speak on
this proposal, please approach a mic.  We'll be closing the microphones
shortly.  And, again, for remote participants, please at least start
typing soon so we know.  
              Steve Wallace:  Hi, my name is Steve Wallace.  I'm from
Indiana University, and I have a question about the proposal.  So for a
simple reassignment, one of the criteria is the prefix is not announced
outside of the upstream provider's network.  
              And I think this may be a core case, but it would be
interesting for some clarity, there are new services, for example, DDoS
scrubbing services -- 
              Paul Andersen:  Which services?  
              Steve Wallace:   DDoS scrubbing services.  So, in a DDoS
scrubbing service, it's possible that the upstream provider
unfortunately might not be aware of a subscriber to a service like that,
and there may be a disconnect between the subscriber of the service, the
assignee, and the assignor in terms of what's going on with that prefix.
 
              And so it might be helpful -- maybe this is an obvious way
of looking at it -- but it might be helpful to be more explicit so that
that's kind of a non-traditional way for things to be announced outside
of the upstream provider's block.  One possibility is the language is
enhanced to directly address that.  
              In the other cases, it might be an argument that you
shouldn't do this, because those kinds of things can happen.  And sort
of consistent with the previous comments, someone not understanding that
that takes them out of the simple case might be essentially changing the
routing situation for the upstream provider. 
              Paul Andersen:  That's an interesting case.  I'm not sure
how it would be interpreted, but the AC can take back that feedback. 
Thank you.  
              Next speaker.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. I support the
proposal.  For the first part, which is to change it to name services,
directory name services, I would suggest adding the word "valid" or
something, or "acceptable" or "accepted."    
              The issue is I don't want to see carrier pigeon over SWIP
being used because there's enough of these services that are turned off
where they're supposed to be turned on, and the people can just invent
stuff.  So just a suggestion there.  
              Alyssa Moore:  Quick question about that first.  So, you
don't think that the language of "that meets the directory services
system," the standard set forth in Section 3.2 is enough?  You think
[it] needs to be added?  
              Kevin Blumberg:  I think that your change takes out SWIP
and RWhois, which is fine.  I agree with that.  But allowing people to
define themselves what is an acceptable system will lead to it being
trolled and abused.  Just put "approved" or "accepted" and "generic,"
and you're fine.  As long as it's that, it will be fine.  
              But otherwise people will just say you need to mail us in
to this address in some country that you don't know, whatever.  It's
going to be abused.  They don't like doing it in the first place, and
this will just give them the reason to do it.  
              I want to talk about, more importantly, simple versus
detailed.  Don't change the records at all.  That is a red herring. 
It's a new proposal.  Please keep this to the very simple thing of
explaining to people when to use a detailed, when to use a simple
reassign.  It's a different policy for the other stuff.  
              I am appalled at the number of detailed reassignments that
are in there that have no reason to be in there in the first place. 
People don't understand simple reassignments and detailed reassignments,
and the reality is anything less than a 24 should not be a detailed
reassignment because ultimately that is an unroutable address on the
Internet.  
              So maybe part of it in terms of your requirements should
be -- and I think you'll find the vast majority of details that are
going in through the API are smaller.  They're 29s and 28s and 27s. 
They're useless as detailed. 
              All they're doing is giving out personal data about a
company, and they are not the abuse contacts that can actually make a
difference because it's not being routed out there.  So I think there is
more that can be done to improve the text.  
              The other thing is I don't -- I'm concerned that you are
limiting it to only the customer requesting.  I have customers who send
email en masse legitimately, but I need them to be there.  And if they
say, no, we don't want to be there, I don't want to handle their abuse. 

              So to say that it must be customer requested, which is --
I understand where it was coming from, limits my ability to say you need
to do this for very valid reasons, and the only way I'm going to be able
to do this is to put it in.  
              So I would definitely look at that.  And there are
customers that will request it when they have no valid reason to do it,
and it creates work on my side as well.  So I would definitely look at
that aspect of it.  Thank you.  
              Paul Andersen:  Question?  Apologize.  Please approach a
microphone soon.  We're going to be closing the microphone in two
speakers.  Please move forward.  
              Joe Provo:  I'm actually representing more than one
speaker. 
              Paul Andersen:  Physical body at the microphone.  
              Joe Provo:  Myself and some remote participants.  
              I'd ask to first put the first slide of the redline up.  I
would disagree with my friend and colleague, Mr. Blumberg, because I do
believe that directory service system meets the standard set forth in
Section 3.2 as language reviews throughout the NRPM, and I don't think
it has a loophole for allowing carrier pigeon carriage of packages.  
              But that's not why I called.  Was it intentional to
completely remove the Whois reference here and only go with directory
services?  Because when I read this, this is only -- this says these
must only be in directory services because we actually struck the Whois
element.  
              Alyssa Moore:  I think that was just in keeping with how
it's referenced throughout the rest of the NRPM. 
              Joe Provo:  I think this has an unintended consequence of
actually removing the SWIP.  
              I support in principle and can support as written as long
as the RWhois thing is clarified.  I'm sure somebody will.  
              And relaying Anthony De La Cruz:  Detailed less than /24
can be needed for abuse.  Need to get feedback loop set up that don't
work with simple, in reply to Mr. Blumberg, who noted it is not needed
for anyone.  And I'm sorry I don't have his affiliation.  
              Brian Jones, Virginia Tech:  I think I support 2018-6 in
principle.  Simple is generally better, but do have a fear of not having
an appropriate POC for an allocation of addresses.  
              Jason Schiller, Google:  Re Kevin Blumberg.  There may be
reasons for smaller than 24 to have a detailed reassignment.  The
customer may want to handle their own abuse.  The customer may want to
publish their location information.  But generally I do agree with
Kevin.  
              Then:  May do publish detailed info simply out of
confusion.  Let's clarify when it's required and when it's permitted.  
              That's that queue.  And that also triggered one personal
thing.  Sorry.
              We do know that there are large entities that have
automated systems which enter detailed for small allocations because
they set them up long before simple existed, and they never changed
their systems.  That was verified when we interviewed operators for that
other POC policy change. 
              Paul Andersen:  Okay, thank you for that feedback.  The
microphones will close in about a minute.  Remote participants
especially, please start typing, since I know there's some lag.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I want
to add two follow-up points.  There's an interaction between this and
the Recommended Policy proposal about third parties creating POCs
because in the case of -- we're now dealing with the fact that if there
is a detailed proposal, the ISP cannot create the POC on behalf of their
client, which may create a problem without setting up the entire
authorized paperwork and having the client register with the [R1]
directly.  So those two things may not go nicely with each other, if I
understand them all correctly.  
              Oh, okay -- 
              Paul Andersen:  Wait your turn, Owen.  
              Michael Casadevall:  Sorry.  And the second train of
thought completely derailed.  
              Paul Andersen:  Oh.  
              Owen DeLong:  I was not trying to derail your train of
thought.  
              Michael Casadevall:  I'll get back in line because it
might come back.  
              Paul Andersen:  Technically we're closing this, but I'll
allow you to get your thoughts together, and you can have the last word,
barring remote participation.  
              So microphones are now closed.  Front microphone.  
              Owen DeLong:  Owen DeLong,  ARIN AC.  Yes, it would be
good to improve the language in 3.2 to better accommodate Joe's concern,
but as I understand 3.2, I would say that ARIN's SWIP qualifies as a
distributed service, meeting the the requirements under 3.2.  
              So I don't see it as being a problem, but it would
definitely be unclear to somebody that was less versed in NRPM fu than
I, and we probably should clean up the language in 3.2 to accommodate
that better for a number of reasons, not just this policy.  
              Paul Andersen:  Thank you.  Sir, the last word.  
              Michael Casadevall:  Michael Casadevall, NARALO.  So the
train of thought came back.  For allocations smaller than a /24, there
are plenty of times where a customer is completely managing those sets
of IPs completely independent of their ISP.  In fact, I see it fairly
common with more technically based organizations.  
              So I think it is not unreasonable to have a detailed
record in there with its own abuse contact, because the ISP is basically
just doing the broadcast due to the limitation that we cannot broadcast
smaller than 24 without doing horrible things to the Internet Routing
tables.  
              Paul Andersen:  Thank you.  Any last words?  All right. 
Thank you very much to the AC for the presentation.  There's no poll
been requested by the Advisory Council chair.  So this ends this
proposal.  
              If you have further comments or questions, please find
your local AC member.  
              (Applause.) 
              John Curran:  Very good.  We are now going to get an
update on the ARIN development work, the ARIN website and the ARIN
Routing Registry.  Richard Jimmerson, come on up.  John, are you going
to join him?  Come on up.  
WEBSITE AND ROUTING REGISTRY UPDATE 
              Richard Jimmerson:  Hello, everyone.  I'm here to give you
an update on two of our major projects.  Inside the ARIN organization,
basically the way we have things structured when it comes to development
projects is we really only work on one large project at a time. 
              Behind that we have some medium and smaller-sized projects
we're working on at the same time, but really only one large project at
a time.  
              One of the projects that we were working on here over the
last year and a half was the website and ARIN Online user experience
enhancements.  I'm going to talk a little bit about that as that project
has just been completed. 
              And we're going to be starting the next large project
space inside ARIN's development, and that is ARIN Internet Routing
Registry.  And John's going to describe that some.  
              So for the website and ARIN Online, we did complete an
overhaul, ARIN.net, on March 2nd of this year.  Basically the new site
is a new, responsive design and an improved user interface.  
              We put a lot of work into user experience enhancements
inside ARIN Online based on feedback that we've received over the years
through this process, through ACSPs, through customer surveys, feedback
that we get from customers on a daily basis over the telephone.  
              And we did, in fact, focus on web accessibility standards
as well, as we do have people contact us who have disabilities that do
use our services quite a bit, and we wanted to make sure that the site
was accessible for them.  
              There was a very strong focus on community engagement with
this project.  We had interactive surveys where you helped us design the
navigation, all the way to the way certain elements look on pages, deep
down inside the site somewhere.  
              Also we did in-person and remote user testing.  You've
noticed over the last two or three ARIN meetings we've actually had
staff members sitting out in the hallways wearing white jackets, doing
user testing, walking you through what it is that we're doing.  
              And we've done site previews over the last year as well
for this project.  We did complete the project with its deployment on
the 2nd of March just here last month.  And there are three blog posts
that we've made this year that you can look at if you want more
information about how we actually designed this, we developed this, how
we used community input to shape the project, and basically what things
look like in the background to get this done.  
              It was more than just a new face for the ARIN website.  It
was extensive changes to how we do everything inside ARIN Online to
service you as the customer.  
              And for every one of you in the audience, there's 100
people not in the room that use the services every week.  And we use
their feedback in addition to yours.  
              I would like to thank you on behalf of the staff inside
the organization for all of the work that you guys in the room and the
people who have attended over the last few meetings have actually put
into this project and your participation in this project. 
              It actually helped us deliver something in response to the
needs that you cited to us.  And we really enjoyed working on it.  And
thank you very much for that.  
              And I'm going to transition over to John Sweeting for the
next slide.  With our major projects, we have our product owners inside
the organization that make sure that community engagement is happening
and to make sure that the staff is building what the community asks for.

              I was the product owner for the website and ARIN Online
changes, and John Sweeting is actually the product owner for the routing
registry project that is starting now.  
              John Sweeting:  I'm John Sweeting, product owner of the
routing registry.  The project is starting now, this quarter.  We're
doing -- we're doing and have done a lot of analysis of prior community
feedback for the IRR.  
              We've had, I believe, two major consultations over the
last three or four years in reference to this project.  We'll be taking
all of that input and feedback and creating a project plan, and we'll be
writing stories for this over this next quarter.  
              Development begins in Q3 2019, although we'll be doing
some development on the routing POC and DNS POC that's been requested
through the ACSP, the ARIN suggestion program.  
              Those will be -- those are starting now.  We're starting
on those.  We're writing stories.  We're going to be developing those
two POCs during the second quarter where we're doing all the planning
and everything from the rest of the IRR.  
              The rest of the development, the main development will
start in Q3.  There's community engagement throughout the project and
plan. 
              We actually have some volunteers that are external
stakeholders in this process.  They will be involved every step of the
way.  They will be invited to meetings.  They will be included in our
theme party that [Deb Barton], in the back back there, is putting
together.  
              So we're not going to go -- we're not going forward blind.
 We're going to be very transparent with this and we're going to share
our plans as we go through this.  The product will be released in phases
throughout, through Q4 2020.  There's probably -- not really sure, but
there's probably three, four, possibly five phases that we'll do
deployments and roll off major portions of the new IRR.  
              Is there any questions?  And if anybody -- if there's
anybody that feels they would like to be a part of this as an external
stakeholder, we do have to keep it limited, but feel free to reach out
to me and I'll talk to you about it and let you know the expectations
and everything, see if there's a fit.  And we'll be more than welcome to
help with this.  
              Kevin Blumberg:  Kevin Blumberg, Toronto Internet
Exchange.  IRR has become very important for Internet exchanges. 
Getting our members and peers hooked in is crucial, and it's a huge
uphill battle with the current free solutions that are out there, such
as ARIN's, and that's why this project exists.  
              Whatever can be done to keep it simple for participants
that do not regularly change their data -- this system is not helpful
for the large organizations that have been doing routing registry data
for years.  
              This system is useful for the people that haven't been
doing it properly or let somebody else do it on their behalf.  
              So whatever easy system, like easy SWIP and all of that,
whatever easy system you can make available to that -- and I would hope
that you are able to talk to the stakeholders from the IXP communities,
I know through MANRS we're doing a lot of work with this, and this would
be a huge assistance to that program as well.  
              So that was just in terms of support of it.  Thank you.  
              What I don't see in here is when you plan to have a
feature set available for viewing for the community to provide any
feedback on.  Is that going to occur during this?  Because I don't see
that between the project start and the development begins. 
              John Sweeting:  This was just a very high level.  That
will be done before the development begins.  When we come up with here's
the plan, here's what we're doing, here's what we're going to develop,
that will be shared before the development starts.  
              Kevin Blumberg:  Thank you and good luck. 
              John Sweeting:  The community is going to be allowed to
have input all the way through this.  Most of the community knows me. 
If they reach out personally or can be an external stakeholder -- you
know John, you know all -- we want the input.  We want to do this right.
 We want to get it right.  We've got one chance to get it right, and
that's what we intend to do.  
              Kevin Blumberg:  Thank you.  
              John Sweeting:  Anybody else?  Okay.  Thank you very much.
 
              (Applause.) 
              Round of applause for Richard and John.  
              (Applause.) 
              We're running a wee bit early, and while I want to release
you to break, and the chairs implored me to let you have more breaks,
having to do with longer breaks and more breaks because of the beautiful
weather and beaches, if I let you out now, there won't even be
refreshments.  
              So, we'll take a few minutes and put one little
presentation in.  It will be Mark Kosters coming up and talking about
the current state of RDAP.  And once Mark is done, we'll go to break. 
Come on up, Mark.  
DEPARTMENT UPDATE: ENGINEERING 
              Mark Kosters:  I'm Mark Kosters.  I head up engineering. 
I want to go through a couple of things that are really exciting that's
going on with RDAP.  
              Who here uses RDAP?  
              (Laughter.) 
              Who has gone to the new ARIN search page?  You've used
RDAP.  
              So, okay, another question.  This is a little bit longer
in the presentation, but I'll go through it now.  Who goes to the
Whois.ARIN.net?  Do you like that better than search.ARIN.Net?  Go ahead
and take a look and tell me what you think.  
              So, anyway, let's go ahead and talk about RDAP and what it
is.  
              So basically one of the things that we've done -- this has
been an age-old dream of mine -- is Whois is a really, really, really
old specification.  It's about as old as the first RFC that came out in
1969, which incidentally I was a little kid then.  I didn't care about
the Internet.  And many of you probably weren't born during that time.  
              So this is a sort of a bootstrap into taking this protocol
and actually modernizing it.  And this is something that Andy Newton in
particular has been working on for a number of years. 
              Our first foray at ARIN was actually this RESTful service
called WHOIS-RWS, which I know many of you have used as well.  The next
part of this was actually bringing it into the IETF in creating a
standard dealing with this.  And it supports both domain name registries
as well as Internet registries.  
              Here's kind of how it kind of looks.  You have basically
your common data types; status structures dealing with it; object
classes, because we like using object-oriented sort of things; and you
get your search results.  All engineers, all developers really like this
new framework. 
              The old Whois was, okay, I'm going to ask a question, and
I hope I get an answer if I do this in this unstructured data format
that I need to actually parse.  So this is a much better way of actually
dealing with this and a more sort of methodical way.  
              Another thing about Whois is really your client -- you may
use JWhois, for example, if you're on a Linux box.  And JWhois has a
bunch of hints in there saying:  Hey, I'm asking for this particular IP
address.  Where do I go?  
              And many of you actually come to ARIN first, saying:  Hey,
I want to know about an IP address in 193/8, which is in RIPE's region,
but you would first come to us, and we would redirect you to RIPE's
Whois server.  
              Well, Whois is just not that smart.  It just goes one
certain place and goes on.  Or it may have some hints in there saying,
well, the com registry is over here, Org registry is over there; I don't
know which server to go to. 
              With RDAP you don't have that problem.  You use this
concept called bootstrapping, where ICANN actually stores who has what,
who has these TLDs and who has these IP addresses.  And here you can see
the concept of, hey, I'm asking for a particular IP address. 
              It comes back and says, well, ask ARIN about it.  You ask
ARIN.  And it says, well, I actually I gave that space to APNIC, and
APNIC is now coming back with the right information.  All this stuff is
seamless to end users.  
              So, let's talk -- you've seen this; you've heard this
before.  Let's talk about updates since ARIN 41.  
              So one of the things that we haven't been dealing with is
flat namespaces like names.  And this is something that has been in IETF
and has been worked on and is dealing with object tags.  And there's now
a way of actually figuring out which registry has the contacts, and you
can go ahead and ask them.  
              There's also some adopted work that's going on.  One is
federated authentication with open ID.  This is something that ARIN
Engineering has been working on for a period of time as well to have --
basically allows you to have more results if you're authenticated. 
Right now you're capped at 256 entries.  This way you can get more than
that.  
              You have paging and sorting of results, reverse searches,
and under discussion is a jCard replacement.  JCard is the specification
on dealing with users and how users in their postal addresses are
supposed to be.  
              Different users in different areas of the world have
different ways of looking at both names as well as the location where to
send their mail.  And jCard really doesn't specify this very well.  
              It's something that's being looked at.  It's actually been
exposed within the regional registries in that people want to see the
same information no matter which region of the world you're going to.  
              There's some other things going on with RDAP mirroring, so
you can actually mirror much like you can with IRR data.  You can
actually mirror RDAP data at a different registry.  
              So here's object tagging.  You can see that these
particular object tags are known for the regional registries.  And here
is work that's going under way with RDAP mirroring, which is something
that APNIC is going forward right now. 
              So RDAP alignment.  There's -- the regional registries
have been working together making sure that all the things -- all our
behaviors are very common and very similar.  
              We had 16 items that we identified at a recent meeting at
the IETF where the regional registry technical people got together and
said, okay, we have these short-term things that we need to fix, medium
term and longer term.  
              And we met together in Prague, and I'm happy to say that
the near-term and the medium-term things we're actually going to have
all done by the end of the year.  
              Incidentally, ARIN doesn't have any near-term or
medium-term issues to deal with.  So the other regional registries have
some implementation things that they need to fix.  
              So another thing that's going on -- going through this
fairly fast -- is that we've added on a bunch of enhancements with RDAP.
 For example, you can query an AS and see all the associated networks
underneath it.  And you can also use CIDR searches as well.  
              We also -- as I mentioned before, our new unified search
site, which is search.ARIN.net, uses RDAP as its search tool.  It's no
longer using Whois.  
              So that's interesting because when we were talking about
the website update, everything now is based on RESTful services.  
              So you have this nice GUI on the front side, but on the
back side it's all RESTful, and that includes RDAP.  And here you can
see a specialized search page that we have for RDAP, so you can actually
drill down to particular objects that you want to take a look at.  You
can actually use this tool much like you can use the advanced search
tool on the Whois.ARIN.net site.  
              And of course for people who like Whois, the old UI is
still there.  I'm not sure for how long. So this is a time-limited
offer.  You can go ahead and use the old site for a while at least, but
it is there for you to use.  
              We also created a new documentation for you guys to start
discovering this and how to use RDAP.  It has a number of cool sort of
features that you can actually code against.  And what's really
wonderful about this is that you can go across all the regional
registries, especially after we got these near-term and medium-term
issues taken care of.  You can do the same coding on all five regional
registries.  
              So, now, let's go on and move on to ICANN.  So RDAP was a
very, very big topic at the most recent ICANN meeting.  Why?  GDPR.  
              Has anyone here actually run a domain registry?  Okay. 
Did you turn off all the personal information, or do you still have it
available?  
              Alyssa Moore:  We leave it by default private (off
microphone).  
              Mark Kosters:  If you use Whois, before, you can normally
go and say, hey, who has ARIN.net.  Actually, I'm not sure if this is
privacy enhanced or not.  
              But, like, you're in my personal domain, for example. 
There's no information about it at all.  You have to go to the
registry -- the registrar to find out who has the contact information. 
It's no longer used in the general purpose, in the general Internet like
it was before. 
              Before, you could actually go from my personal domain and
you can actually see that, hey, I'm a tech and admin contact for my own
domain.  
              That is no longer possible, and the reason for this is
GDPR.  
              And ICANN really, really wants to actually satisfy all the
needs of their constituencies, including law enforcements and
intellectual property rights people.  And they'd like to see some better
exposure than they have today.  
              So this is something that ICANN looked at RDAP and said,
hey, with these access control features that it has with the open ID
stuff that I mentioned earlier, this could be a really cool way of
actually exposing information to authenticated users so you can get some
information back without having to go through additional hoops.  
              So one of the things that ICANN has done is they put it in
their contacts that all registries and registrars need to have RDAP
implemented in six months.  And I believe that's coming in August if not
sooner.  
              So there's a lot of work that needs to be done here to
make RDAP actually happen, but it's occurring.  
              So one of the things that the CEO of ICANN said is I want
to create a technical services group that actually deal with RDAP in our
community and make this happen.  
              You can see this group of people here, and you may have
noticed that the chief engineer for ARIN is actually in the front.  And
that's Andy Newton.  He was at ICANN 64 and actually grappling with
these issues.  
              So, again, it's very much in the forefront.  This is
really, really big.  And I'm excited about it because I'd really like to
see Whois go away and actually replaced by RDAP.  And ICANN has actually
helped put that in place as well.  
              And here you can see -- DNR stands for Domain Name
Registries -- and you can see since ARIN 41 to 43 that we have a lot
more TLDs that are actually serving up RDAP.  And so this is great
seeing this core protocol, Whois, being replaced by a newer core
protocol called RDAP.  
              So with that, any questions?  
              Cathy Aronson:  Hi.  Cathy Aronson.  I don't have a
question.  I just have a mini speech.  No, just kidding.  
              (Laughter.) 
              I just wanted to say that I am so excited for you, because
almost the entire time I've known you, you've wanted Whois to go away,
and this is just awesome.  
              Mark Kosters:  Yeah, thank you.  Thank you.  So just a
little forefront, who here uses RWhois?  
              Unidentified Speaker:  Retired it.  
              Mark Kosters:  Great.  So I helped create RWhois as a
replacement to Whois, but it didn't make it.  This one I hope one will. 
In fact, it will.  So, I'm excited about RWhois going away as well, even
though it's one of my babies.  
              Joe Provo:  Jason Schiller, Google:  Do we have full
one-to-one support for all of the existing Whois flags -- query by
record type, network ASN, POC or customer, query by attribute, domain
and handle name, disable flags, dot, dot, dot, dot, dot?  
              Mark Kosters:  I believe a good number of them are there,
if not all of them.  Admittedly, Whois-RWS actually has some more
features than RDAP does, because RDAP is actually a standardized
protocol, whereas WHOIS-RWS has more things that you can actually do --
queries, hey, show me all the prefixes shorter than this length, that
sort of thing.  That's not in RDAP.  But most of the major queries are
there.
              Joe Provo:  He's still typing.
              Mark Kosters:  Is this Jason?
              Joe Provo:  Yeah.  I'll come back.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I have a
technical question.  What prevents man-in-the-middle from the bootstrap
servers to the end registries in case of state-sponsored censorship or
similar use cases?  Is there cryptography keys or something to the KSK? 

              Mark Kosters:  So there's -- all this is done over https
transport, so they need to have a cert associated with that that's
validated.  
              Michael Casadevall:  Okay, thank you. 
              Mark Kosters:  You're welcome.  
              John Curran:  We're going to close the mics shortly, so if
you have a question, remote, or at present, please get to the mics.  
              Joe Provo:  Jason Schiller, Google:  Can we make sure we
have full one-to-one support and how to manufacture the queries prior to
killing Whois?  
              Mark Kosters:  That's certainly a very valid request. 
              Joe Provo:  Thank you. 
              John Curran:  Go ahead, Andrew.  You're the last.  
              Andrew Dul:  Andrew Dul.  I just noticed that there are
differences in being able to sub-string search by -- sub-string search
on, like, name records.  I haven't figured out how to do it in RDAP yet.
 Maybe that's my issue.  
              But if you just want to throw a sub-string search in for a
part of a company name, doesn't always seem to return the same things
between Reg-RWS and RDAP. 
              Mark Kosters:  Yeah, so maybe we can sit together and go
through some of this a little bit later.  All right.  
              John Curran:  Thank you, Mark.  
              Mark Kosters:  Welcome.  
              (Applause.) 
              John Curran:  So I said you guys were going to get a
break, but I lied.  So I'm going to bring Richard up.  The chair has
asked to reorder things because it will provide potentially more free
time at the end of the day.  
              So we're pulling a presentation up from the end of the day
while we get towards the break.  So this will be the last presentation
before the break, for real this time, and it will be Richard Jimmerson. 

              He's going to talk about ARIN meeting agendas, like the
meeting we're having and the agenda we're having and how we're
rearranging and where we decide what goes on in the meetings.  Go ahead,
Richard.
COMMUNITY INPUT INTO FUTURE MEETING AGENDAS 
              Richard Jimmerson:  Thank you, John.  If you think I've
been up at the microphone too many times today, then this presentation
is for you.  
              So, from ARIN 1 in the late 1990s all the way through ARIN
44, which is the October meeting coming up later this year, the agendas
have been set by the ARIN staff organization.  
              Basically what we've done is we've looked at all the
policy discussions that are active inside the process.  We've given
prioritization to those on the agenda.  And we've basically filled in
the holes everywhere else as the staff.  
              Occasionally we would reach out to the Board and the AC
for items that were of interest to them, and occasionally things would
come up on the Mailing List or in other places that would dictate things
that we did put on to the agenda.  But basically it was driven by -- it
has been driven by ARIN staff.  
              What we're proposing is, starting with ARIN 45, which is
the Louisville meeting next year in April, we want to change that.  So
at the beginning of the year, we would like to change -- after the
October meeting this year, we'd like to change how agendas are created
for these meetings.  
              And the way that we would like to change it is by removing
the staff organization from being the group that decides what's on the
agenda.  So, what we envision -- and we'll have more discussion about
this throughout this year -- is that we would do an open call for
content submissions and suggestions, much like we did back in the first
few ARIN meetings where John Curran or Kim Hubbard would send an email
to PPML and say:  The meeting is in a month; what would you like to be
on the agenda?  
              The agendas would be set by a program committee instead of
the ARIN staff organization.  That committee could include community
volunteers, elected AC members, and ARIN staff would be there for
support to that committee as part of the committee.  
              All agenda items would be vetted before the hotel rate
cut-off.  Basically what we're saying there is there would be a timing
requirement on when we would have to have the agenda set based on
decisions that we had to make with the hotel and our contract and those
types of things.  And it also allows people to arrange travel who might
be speakers.  
              And open agenda space would be filled as available by this
program committee, but the policy discussions themselves would continue
to take precedence.  
              It's very important that all of the policy discussions be
on the agenda and that they be spaced appropriately, giving the
appropriate amount of time, and they be basically set in stone so that
remote participants would be able to tune in reliably when those are on
the agenda and be able to participate without being in person.  
              The potential benefits to making this change is the
community involvement would improve transparency in the agenda creation.
 A lot of people have wondered in the past, perhaps, how do you create
the agenda, why is this on the agenda, why isn't this other thing there.

              And of course it's come up in our surveys that we did with
the community for customer satisfaction.  The way that we create the
meeting agendas was rated one of the lowest items of something that they
thought we were doing good or bad.  
              New content opportunities, community member studies and
outcomes could come in.  We could have technical case studies for DNSSEC
and RPKI, community-led panels on registry-related topics.  
              And we expected it would promote wider participation and
attendance for future ARIN meetings in the Policy Development Process,
because if you're involved in actually creating the agenda yourselves,
your peers may be more interested in coming to this meeting than they
are today as it's created by staff.  
              So, questions to the community.  If there's a discussion
here, these are the types of things we'd be interested in starting with.
 Of course, there's more time to discuss this in the coming months, but
does the proposed approach work?  Are there any topics you'd like to see
that we don't cover now?  Is there a another desired approach you'd like
us to take with agenda setting?  
              John Curran:  Questions.  The microphones are open.  
              Kevin Blumberg:  Kevin Blumberg, just myself.  I was on
the NANOG program committee, a group of volunteers who did exactly that.
 
              This is not going to work for ARIN.  There are too many
things that are mainstays that have to stay.  
              And my bigger question is:  What is left that is optional.
 There are some updates that we can take.  You used them as filler, et
cetera, because you don't know how many policy things are going on.  But
I can't have -- I'm talking about me -- I can't have you take away the
Staff Experience Report because five people in a room decided it's not
that important. I can't come to this meeting without some critical key
things.  
              So how much time is actually left that we can program
around?  Do you want to add a day before to do some technical things? 
Is that part of this?  I'm trying to understand where you're going with
it, I guess. 
              John Curran:  So there's approximately an hour a day that
is based on the average AC workload and what we have to report.  There's
still about an hour a day.  In fact, there could be two if we squeezed
the breaks down and had you guys really work hard.  But let's say
there's only one because we're not going to be mean.  
              So, we do presently open up the meeting to select
presentations.  We're going to see one shortly on economic factors and
IPv6 deployment.  There's one tomorrow on the UPEN study on RPKI.  
              Right now the decision-making for what that is is somewhat
ad hoc.  It's completely opaque to you folks.  It involves me and the
team and what the staff brings to me that waits, to the point where I
go, okay, let's put that on the agenda, you get on the agenda. 
              Now, if you're saying you love the agendas and you love
the job I'm doing, that's great.  But the reality is that we don't have
a call for presentations right now.  There could be more good content
that people want to see, and there could be more presentations like the
ones we're going to see today and tomorrow.  
              But for those one or two hours that we do have, not taking
away from the things that you must have to get your job done, but for
the slack in the agenda, the question is:  Do you want a program
committee and do you want to call for presentations in case someone has
something useful they want to present to the ARIN community?  
              Kevin Blumberg:  Thank you.  Please define what is not on
the table for this discussion.  The one or two hours, that's great.  But
I noticed, John, that on this call you had 15 minutes for open mic,
where we used to have an hour or 30 minutes, or whatever.  And maybe
it's because people just aren't interested in doing open mic, but some
of the things have really changed. 
              John Curran:  Let me turn it around.  What is not on the
table, Kevin?  What do you not want to be on the table?  What is
required?  Obviously the policy presentations that are specified in our
RDP.  Obviously there are reports, like the Policy Experience Report,
the Number Status Report, and there are certain staff reports.  
              So, beyond that, do you need to know that, no matter what,
we're going to have an hour for open mic?  
              Kevin Blumberg:  No, open mic was an example where I
noticed a change.  The question becomes do we need the global updates,
because that is two hours.  And for me, personally, I would like to see
the global updates.  I believe they're an important part of being part
of the RIR system.  But that's a huge chunk that could be, well, do we
need it for everybody. 
              I would like to see what's, like I said, on the table and
off the table.  If you've got an extra hour, great.  I think having a
small group of people that can vet stuff, wonderful for that hour, you
know?  
              But to me there isn't a huge amount of time -- this isn't
programming the whole thing, it's just a small amount.  
              John Curran:  Understood.  
              Cathy Aronson:  He was up first.  
              Peter Thimmesch:  Peter Thimmesch with Addrex.  We're
completely in favor of this because it does enable different discussions
and people to come in.  
              I think a combination of what Kevin's concerned about,
which is a set set of things that are always in all meetings, it's just
[basically route], but having an outside program committee of people
that are established and able to bring in people will bring other people
involved, it will get a larger attendance, it will get more information
that are core and relevant to members and to community.  
              So I can't see how that's a bad thing as long as you do
keep your set structural things that you always have at meetings, which
seems to be repeated in all of them.  And I think it's actually a good
thing.  
              Cathy Aronson:  I'm Cathy Aronson.  I just had a question.
 So what about the fall meeting?  Because it's really abbreviated
compared to the spring meeting and done in conjunction with NANOG.  Is
that going to change somehow?  Because there's not usually extra time in
that agenda.  
              John Curran:  We would usually restrict the fall meeting
to a very small number of external presentations, like a slot or two of
20 minutes, 30 minutes tops.  We really don't have a lot of slack in the
fall.  We have far more flexibility in the spring. 
              Richard Jimmerson:  And as an interesting aside, it's the
reason why we're proposing we start this in the spring of next year
instead of the fall of this year.  
              John Curran:  We don't have to do this if no one's excited
by it.  I can use my crystal ball.  I haven't failed so far, I don't
think.  But openness is good.  
              Paul Andersen:  I've also been getting more, the same way,
John.  I'll get people who have approached me saying "I've got a great
paper" or "Would the Board consider letting this get presented?"  
              And we don't have a good process for that.  That's why we
thought -- I don't see it as so much just the entire agenda as being
thrown over, but is there a better way that the community can help us
figure out what is interesting content to augment the other very
exciting policy and ARIN administration presentations that I think would
continue to be there in some form.  
              Joe Provo:  Brian Jones, Virginia Tech.  Just a
suggestion.  There could be a public section during ARIN 44 for
developing a backlog of agenda items which could be prioritized and
voted on as additional items to the policy discussion and mandatory
reports.  
              Richard Jimmerson:  Thank you.  
              John Curran:  Back microphone.  
              Alyssa Moore:  Alyssa Moore, Canadian Internet Registry
Authority.  I would support something like this for whatever the hours
of slack time, half an hour of slack time, to be able to have the
community decide do we want to see a presentation about the economics of
IPv6 or outside studies of RPKI.  
              I would like the opportunity to engage and have choice of
a call for presentation, so I support it.  
              John Curran:  Microphones are closed.  
              Front mic.  
              David Farmer:  David Farmer, University of Minnesota, ARIN
AC.  I like this idea.  My suggestion is let's try it for a couple of
years.  Don't say that this is the way it's going to be forever yet
until we know we like it.  That's it.  
              John Curran:  Okay.  Understood.  I just managed to mutter
the words "Microphones are closed" and you then got up, Chris.  Chris,
can I help you?  What do you have?  
              Chris Tacit:  I just wanted to say that I think this is a
great idea.  
              John Curran:  Wonderful.  John, did you need to comment?  
              John Sweeting:  I needed to answer?  So there was a
question on initial requests.  So, I got reading on initial requests
since January 2017.  We've had 328.  It's about half and half end user
and ISP.  End user is limited -- it's justified a /24 without
justification, and ISPs are approved /21 without justification for that.
 
              Under 4.10, there's 16,384 in the pool, of which 536 have
been used.  So there's 15,848 /24s still available.  
              And on MDN, since it was approved, we've had 282 requests.
 So that's like 2.8 percent of all requests for IPv4.  Once the 24-month
rule went into effect, we're down to -- it's .1 percent of the requests;
we've had like two.  And the average [sites] in those requests were
between five and seven.  
              John Curran:  Okay.  Thank you.  
              We'll let John clean his work queue.  Very nice.  Any
other questions for Richard?  Anything remote?  Round of applause. 
Thank you, Richard.  
              (Applause.) 
              Okay.  I said I'm going to give you a break but -- no, I'm
actually going to give you a break this time.  Wouldn't do that twice. 
That would be cruel.  
              Okay.  So, folks, we'll have a break outside.  There's
refreshments.  We'll come back at 3:30, promptly.  
              We're going to handle ARIN 2019-1 on clarifying IPv4, and
ARIN 2019-3.  So we're now broke.  Come back at 3:30 promptly.  Thank
you.  
              [[BREAK] .] 
              John Curran:  If the people will come in, we'll get
started.  Hopefully everyone had a wonderful break.  We have two more
policies to get through, and the first policy is ARIN 2019-1: Clarify
IPv4 Section 4 IPv4 Request Requirements.  
              This is a Draft Policy, and as such there is no staff
introduction.  It is not going to be potentially sent to the Board after
this meeting.  It's going to definitely come back to you.  But the AC
would like to present and get some input, so I'll invite Kat Hunter up
to give the presentation.  Come on up.  
              (Applause.)
ARIN-2019-1: CLARIFY SECTION 4 IPV4 REQUEST REQUIREMENTS 
              Kat Hunter:  Good morning.  I'm Kathleen Hunter.  I go by
Kat.  This is Draft Policy 2019-1.  Myself and Amy Potter are the
shepherds on this policy.  
              So the full problem statement is up there.  I'm not going
to bore you with the entire thing, but in January there was a
face-to-face meeting where the Policy Experience Report was discussed
with the members of the Advisory Council.  
              ARIN staff has observed a pattern where the
organization -- where an organization transfers space under 8.2, which
is mergers and acquisitions, to a specified recipient and immediately
applies for space on the waiting list after that, the activity appears
to be speculative in nature and not consistent with sound address
management policy.  
              So the policy goals, there's two here:  Clarify the
waiting period to only prohibit requests for IPv4 allocations under
Section 4 of the NRPM; and disallow organizations that have transferred
space to other parties within the past 12 months from applying for
additional IPv4 space under NRPM Section 4.  
              So this is the current policy as written.  Repeated
requests in a manner that would circumvent 4.1.6 are not allowed.  An
organization may only receive one allocation assignment or transfer
every three months.  
              So in bold is where that's actually going to change.  An
organization may not apply for IPv4 address resources under the section
if they have received an allocation assignment or transfer of IPv4
resources less than three months prior or the organization has
transferred space to another party under Section 8 less than 12 months
prior.  So if you've transferred space out, you have to wait 12 months. 

              PPML reception has been generally positive.  So most of
the discussion was to keep the two topics, the two goals together.  This
should curb bad practice, and anything that clarifies Section 4 is
welcome.  
              So some discussion points.  These policy goals are
severable if the community prefers to address them independently.  
              There are a lot of other discussions that are ongoing
about future policy changes for the waitlist.  Do you believe this
policy is worth pursuing as a potential stopgap for bad behavior,
knowing that larger policy discussions are going on?  
              Something I didn't list on here but was brought up a
couple times in the last day or so, is 12 months enough time?  Would you
rather see that number go to 24 months?  Is it too long?  Too short?  
              And that's it.  
              Paul Andersen:  The microphones are open.  This is Draft
Policy, so we're looking either for feedback on your support or not for
the policy statement or the problem statement.  So, please approach a
microphone.  And rear microphone, please.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. I support the
policy.  In regards to the 12 months, I believe if a staff member or
somebody from the APNIC region could comment, I believe that their
latest policy had a five-year restriction, and if somebody wants to just
clarify that.  
              I think that that's probably too long because this is
dealing with a number of things.  But I don't know if 12 months --
excuse me, I don't believe 12 months really curbs anything.  
              What we've seen with other things is people are willing to
wait.  So I would probably look and be very -- I would personally be
okay with 36 months.  And looking at something like that, you could
obviously poll the list of people, but I don't think that 12 months is
enough time.  The rest of it, absolutely this is a good cleanup.  Thank
you.  
              Paul Andersen:  Thank you.  Others that wish to speak in
favor or against the concept, policy, suggestions, questions?  Rear
microphone.  
              Tony Smith:  Tony Smith from APNIC.  Just to clarify the
comment, prop-116 passed in our region, I believe it was 2017.  It was
related to our final /8.  The Policy Proposal initially asked for all
transfers from the last /8 block to be banned.  That then changed to a
two-year period.  And then from the final consensus call it changed to
five years, and that's what passed as policy.  So, that's for our final
/8 block. 
              Paul Andersen:  Thank you for the clarification.  
              Rear microphone.  
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  I
initially submitted this proposal.  I obviously support it as written.  
              Paul Andersen:  You never know with this crowd.  It's good
to clarify.  
              Chris Woodfield:  But I'm absolutely perfectly happy with
longer time periods that have been proposed.  12 months was an initial
stab.  Seems like the community is coalescing on something longer than
that.  And I'm perfectly okay with that.  
              Paul Andersen:  Okay.  Thank you.  Other comments?  For
those that are new, The esteemed AC locks themselves in a room and tries
to take all this input and decide what to do with this policy.  And the
input they get right here is really important to that.  It's great if
you can come up and speak into a microphone.  
              We'll close the microphones soon if nobody comes.  Please
approach a microphone quickly.  I see a remote participant back and
forth.  I think he's still getting it.  So why don't you go ahead.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I'm
supportive of this because an organization that requests an IP block and
then transfers it out immediately is either gaming the system or
basically shot themselves in the foot, they didn't need the block in the
first place.  
              So I'm looking at this as a way to drastically reduce
abuse of Section 4 and requesting IP blocks.  
              I actually feel like 12 months is too short, and I would
be much happier with a longer period with an exemption that if the --
that if the party that received the block can document why circumstances
changed, they can then have that waivered on a case-by-case basis.  
              But I feel like a strong line against gaming and hoarding
blocks is very much the way to go, given IPv4 exhaustion. 
              Paul Andersen:  Thank you for that.  
              Again, I urge you to approach.  We'll be closing the
microphones after the remote participation if we don't see someone
moving to a mic.  
              Joe Provo:  I'm proxying multiple remote participants and
also have my own two cents.  
              Jason Schiller, Google, ASO AC:  I support the proposal
with a restriction of 12, 36 or even 60 months, but it should not apply
to M&A activity.  
              Next, Andrew Gallo, GW:  I would suggest a longer time,
36, 48, 60 months.  
              Brian Jones, Virginia Tech:  I support Draft Policy
2019-1.  I would also support if the waiting period were extended to 24
months or longer.  I like the idea of addressing both issues for
requests and transfers in the same section.  
              Paul Andersen:  Thank you very much.  And you had your
own.  
              Joe Provo:  My comment was:  Longer, please.  
              Paul Andersen:  Lots of feedback on the length.  Great to
have.  Front microphone. 
              Rudi Daniel:  Rudi Daniel, ARIN Fellow.  I'm in support of
the policy.  I'm also in support of the longer time period.  Certainly
more than 12 months.  
              But I think there should be some safeguard built into
that, because supposing someone -- the conditions change, if there was a
36-month period and the conditions changed within that period, then
there should be some let-out clause. 
              Paul Andersen:  Okay.  Thank you.  We'll keep the
microphones open because the flow is going.  We have the time.  We're
not trying to cut it short.  We don't want to sit with too much dead
air.  
              Rear microphone. 
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  I
wanted to address the last comment that there's current language in that
section -- I'll read it out loud.  
              Actually, it's on Slide 4, I believe, if you want to go
back to that.  
              Yes, the final sentence there that starts with "ARIN at
its sole discretion," that is that let-out clause that you're referring
to, I believe.  
              Paul Andersen:  Lots of time on the discussion and the --
any feedback?  
              Michael Casadevall:  Michael Casadevall, NARALO.  Just
bringing up on the policy of [own discretion].  
              That may be a little bit too vague.  It may be better to
have a strong set of guidelines that go into what a waiver involves so
the process is consistent, just based off my experiences on how various
waivers have worked in ICANN in the past.  
              Paul Andersen:  Thank you for the input.  Again, I'm now
going to close the microphones after this comment.  So please come to
the microphone if you would like to make a comment, or start typing.  
              Rear microphone.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. The last part
related to the waiver.  I would like to ask the staff in front, would an
M&A be considered a change in circumstances that would allow for it? 
Because that sort of addresses Jason's concern from earlier.  
              And I don't have a problem with the ambiguity there,
because I think the reason for that ambiguity is to prevent gaming that
we've seen in other ways.  
              So while I would love -- I know that having specificity is
wonderful.  I believe that that sole discretion was put there because if
you start documenting it all, it's just an abuse vector.  
              So I guess to my first question, which is the most
important, would an M&A be considered a change in circumstances that
would then be used?  
              John Curran:  We evaluate M&A on a case-by-case basis. 
It's not the M&A.  The M&A itself, you can take two entities that are
operating with address space and functions, and you combine them.  And
the functions remain and the address space remains, then the combination
doesn't create in and of itself any change in overall circumstances. 
Okay?  So an M&A would not necessarily trigger.  
              You have an M&A where you're divesting units and
businesses are going there and addresses are going here, yes, you may
have a circumstance that on a case-by-case basis we need to accommodate.
 Depends on the particular of the M&A. 
              Paul Andersen:  Microphones now closed.  Can you flush our
queue?  
              Joe Provo:  I realized when I made my personal comment I
did not drop my affiliation.  Joe Provo, Google, ARIN AC.  Support in
spirit and longer, please.  But we've got to do something.  So yay.  
              Remote participation:  Jason Schiller, Google, ASO AC:  An
address holder that finds they're holding unneeded IP space could always
return it to ARIN or another RIR or IANA as applicable with no penalty,
right?  
              That's it.  
              Paul Andersen:  Thank you.  That closes the discussion. 
Thank you very much.  Kat, as this is your first presentation, you win
these lovely glasses, if you need them.  
              (Applause.) 
              Thank you for your presentation.  
              John Curran:  We'll continue the policy block with the
last policy of the day, and this is Draft Policy 2019-3: Update the 4.10
IPv6 Deployment Block Requirements.  
              Alicia, come on up.  
ARIN-2019-3: UPDATE 4.10 – IPV6 DEPLOYMENT BLOCK 
              Alicia Trotman:  This policy, myself and Owen are the
shepherds.  
              Let me give you a little background.  This is the problem
statement.  There's an implementation issue with the current text as
written, as well the 4.1 as currently written a /28 is the minimum. 
However, ARIN allocates /22 as its minimum size.  
              The current RPKI landscape is also impedement to using
this block size.  As well the /28 is pretty much unroutable practically
on the Internet, which leads to requiring a solution for this.  
              This is the updated text.  Let me put some of the changes
in perspective for you.  The first change to the paragraph -- this is
pretty much editorial.  It doesn't change the meaning of it.  It was
just a swap of a couple of words.  And I will move to the next change.  
              This is where we get on to the meat of the matter.  So the
current text, it states that the block size would be subject to a
minimum of a /28 and a maximum of a /24.  ARIN should use sparse
allocation when possible within this /10 block.  The author would
like -- the block will be subject to a minimum and a maximum allocation
of a /24.  ARIN should use sparse allocation when possible within this
/10 block.  
              Second change -- this is in the conditions -- this is
condition number one.  Currently it states "The applicant may have
received resources under the policy in the preceding six months."  The
author would like it changed to "The applicant may have received
resources under the policy the preceding six months and cannot receive
more than a /21 under the policy section.  
              Condition number three has also been altered.  It
currently says "Previous allocations/assignments under the policy must
meet the utilization requirements of the end user assignments."  
              The author would like "Previous allocation/assignments
under this policy must be utilized to at least 80 percent to obtain an
additional allocation or assignment."  
              They brought the end user requirements to 80 percent into
this policy so that it would standalone, 4.1 would standalone by itself
and doesn't reference the user assignments.  
              Condition number five that is currently in the text has
been completely removed.  
              So a summary.  These new major changes that have been made
raise the minimum size to a /24 and limit the amount an organization can
receive to a /21.  Secondly, removes this -- the new text removes the
requirement for the return and renumbering.  
              Thirdly, clarifies the utilization requirements by placing
them directly into 4.10 rather than referencing the utilization
requirements of the end users.  
              And that is it.  Any questions?  
              (Applause.) 
              Paul Andersen:  The microphones are open on this, our last
policy.  Come one, come all.  Come to the microphone.  Front microphone,
please.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I've got
multiple comments to make on this.  So while it is not practical to
route a /28 in and of itself, it would be possible -- we encounter this
problem on 44NAT.  For those who are not aware, that's the ham radio, 44
/8.  
              And how we handle this is that we group blocks smaller
than /24 together within a region so they can all be routed from a
single endpoint so multiple customers can handle that.  
              So the practicality of having an allocation smaller than a
/24 is not necessarily a bad thing because it prevents customers from
having more IP space than they need and may be possible to solve via
mechanism of aggregation.  
              Secondly, in reverse DNSSEC terms, it is possible,
although granted uncommon, to actually subdelegate right down to the
individual IPs [via NS] delegations from the third level of the reverse
lookup zone.  
              It is possible, granted painful, that a customer could
manage the reverse DNS by simply having NS records for each individual
IP address within their block. 
              This would make lookups a little bit slower in practice
but it would be possible if not exactly practical.  
              Finally, I am somewhat concerned on having a higher
minimum.   I already addressed that.  I think those are my points.  
              Paul Andersen:  Thank you for that.  I think the comment
on the block at least as I read it was not so much that it's not
technically possible to do the DNS, it's just the tools and back end
systems would require significant upgrade.  
              Front microphone.  
              David Farmer:  David Farmer, University of Minnesota, ARIN
AC.  The /28 was when we were going into runout was the idea that maybe
we were going to change what was routable.  That did not occur.  Let's
just move it to the /24.  I support the policy as written.  Thank you.  
              Paul Andersen:  Thank you.  Microphone here on the side.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. I support the
policy.  I want to bring up a couple comments.  The first is I already
authored the exact same thing three or four years ago to change it to a
24 and that was abandoned for a very, very good reason.  
              It was abandoned at the time because people said
legitimately there are use cases where we don't need it routable; we
need unique identifiers for OSPF or for whatever it may be.  We don't
need it and there's no reason to do it.  
              The reality is that most of the space that's going out
does need to be routable.  But what I would suggest with the draft text
is allow smaller blocks when the person requests it but default to a 24
from a staff perspective.  
              So if there are people that need a 28 to handle their
internal routing -- their internal router IDs for BGP or OSPF, whatever
the case may be, and they're happy with that, I don't think it will be
used.  But that was the concern back then. 
              The default if it's going to be routable it does need to
be 24.  And all of the statistics have shown that.  
              The second thing is I don't like the /21.  When we've been
talking about all sorts of other areas a /22.  I would like to
understand why /21 was chosen where we're choosing /22 as sort of the
maximum allocation size for other things.  I would be more comfortable
keeping it consistent of a 22.  But overall I 100 percent support this. 
              Paul Andersen:  A comment why 21 was picked?  
              Andrew, do you want to line jump for a second?  
              Andrew Dul:  So /21 was picked because I thought /22 was
too small.  This is not an aggregatable block because all the 24s will
be sparsely allocated.  There's no aggregation in here.  It's separate
/24s up to a /21.  
              Paul Andersen:  Thank you for that.  Kevin, does that
address your question, maybe not change your position?  
              Kevin Blumberg:  This is a finite, very small pool. 
16,000 is not a great amount.  It's meant to kickstart.  So I still
believe that a 22 based on everything else is probably more appropriate.
 And that would be my suggestion.  
              Paul Andersen:  Okay.  Thank you for that.  Please
approach the microphones because the microphones will be closing if we
don't have a queue to fill.  Front microphone.  
              Joe Provo:  Remote participant proxies:  
              Jason Schiller, Google, ASO AC.  I'm confused about what
problem 2019-3 is trying to solve.  If a customer asks for a 28 of v4 in
support of v6 transition, can ARIN not give them a 28?  
              Upon ARIN giving them a 28 and noting that [RD and S and
RPKI] won't work, can't the customer still take the 28 if they need it
only for BGP router IDs and thus don't need it to be widely routed or
RPKIed or have working RD and S.  And if a customer says, oh, not RD and
S, can I have a 24 then?  Can't ARIN give them a 24?  
              Paul Andersen:  Repeat the last question again.  
              Joe Provo:  Should they receive the 28 and then say, oh,
gosh, it needs to be a 24, can't ARIN give them a 24?  
              John Curran:  Justification for 24 is significant compared
to them getting a 28.  We don't issue 28s right now.  
              I'm not sure -- unless you guys make some radical changes,
I'm not sure we ever would.  The question lacks real word context to me,
I guess.  Are you proposing issuing less than 24s?  Smaller sizes?  
              Joe Provo:  28 is covered under the policy that's trying
to be changed. 
              John Curran:  I'm sorry.  I guess what I'm trying to say
is if someone came and got a 28 and then they wanted to come back and
get a 24 instead, if there's enough space available and we allocated the
24 in a sparse manner, we could do that.  I'm not sure we're going to
have the space to do that.  
              So the answer would be no, I expect.  
              Andrew?  
              Paul Andersen:  Can Andrew line hop for a second again?  
              Andrew Dul:  So this is the use case as I understood it. 
If you ask for a 28 for location A and receive a 28 for location A
knowing the caveats around routability, RPKI and whatever, and then what
ARIN does in the database is actually issue you a 24 because it can't
issue you a 28.  
              Then when you come back and say, hey, I need another /28
for location B, six months later or longer, ARIN says, well, you don't
qualify because you haven't filled up your 24 yet. 
              That's the use case that we're trying to squash with this
policy, amongst others, if I understand -- 
              John Curran:  Every time we do that we need to administer
DNS which turns out to be an adventure.  
              Go ahead, John.  
              John Sweeting:  Basically they would argue later and say
we did not ask you for that 24; we only asked you for that 28.  Now
we're asking you for another 28 because we can't use the rest of that 24
based on what we asked for and how we're using it. 
              John Curran:  Right.  I don't think our internal
reservation of a nibble of space, a 24, because someone's asked for 28
on a nibble boundary, the fact that we have to do something bigger does
not mean that we need to recognize that you need to fill our internal
database allocation.  
              So if you've got a 28 and you're entitled to get another
28 because you used the first one, I would imagine we'd work to
implement that so that's not a problem.  
              The fact that we might allocate that out of a 24 and not
put anyone else in it for our own reasons should be an implementation
issue, not a policy constraint on someone requesting more space.  If it
is a policy constraint on someone requesting more space, I'll fix it. 
              Paul Andersen:  Andrew.  
              Andrew Dul:  That's the use case that was described to us
at the policy experience report in January that prompted this policy. 
Unless I misunderstood how you're planning to fix it, then -- 
              John Curran:  Presently we do allocate -- we have to
allocate things on 24 boundaries because amongst other things reverse
DNS requires it.  Okay.  
              I'm not sure -- I guess the question that comes up is
you're saying -- what I'm lost about in this use case is whether or not
we've had someone actually come back and do that request. 
              Paul Andersen:  Yes. 
              John Curran:  And they were turned down because we had a
24 allocated to them and they couldn't get a second 28 from within the
24 because they thought they only had the 28, even though we allocated a
24.  
              Andrew Dul:  [Inaudible]. 
              John Curran:  Right.  I see the problem.  If you take that
into consideration, then they have all the 28s in that 24 and we gave
them a second one, because they asked for a second one.  
              But the policy doesn't clearly support it.  Okay.  So we
know what we all want to do here.  We don't want to have them qualify
according to a 24.  We want them to be able to get the second 28 in the
block of 24 we already put aside without them justifying against a 24. 
Right?  
              Paul Andersen:  This seemed so much easier 10 minutes ago.
 
              John Curran:  Is that the goal of what you're trying to
solve?  
              Andrew Dul:  I think we're trying to solve multiple things
here.  This was prompted by the use case that we discussed and I tried
to illuminate here maybe incorrectly, but as I understood it. 
              But I think the other issue we're trying to solve with
this policy change is actually moving the boundaries so that we have --
give people routable blocks to avoid the confusion of you gave me this
28, I can't use it.  Now I need a 24, to just cut that whole process out
and give people 24s.  
              I'm sensitive to Kevin's comments about, well, people
might only need a 28 for their OSPF router IDs.  And, honestly, I don't
care if we give them 255 instead of 16.  That's fine with me.  
              The people who want to ask for OSPF router IDs that really
need them, they can have 255, because I think there's not very many
people are going to do that.  
              John Curran:  Based on the Policy Experience Report, we
have a working way forward that we've done but it's not reflected in
policy.  So you can adjust the policy and that would be a good thing. 
It's not a crisis one way or the other. 
              Paul Andersen:  But luckily we have 2019-3 that proposes
to fix this.  It's a miracle.  Can we get some semblance of a line here.
 You've become the mic huddle.  
              Joe Provo:  We're nesting too deep.  
              Clarification from Mr. Schiller.  Then there's another
remote participant.  
              Jason Schiller, Google, ARIN ASO AC.  My read of 4.10 says
if I get one unit of 4.10 resources and want another unit, then I may
need to renumber.  
              So bumping up to a 24 may mean renumbering.  Renumbering
is not a reason not to give out 28s.  My use case is I asked for a 28. 
I made a mistake.  Can I give back my 28 and get a 24 with the
justification I used for the first 28 which is bootstrapping IPv6?  
              I don't want to cut out the process, but want to clarify
that it's easy to trade up from a 28 to a 24 if they're willing to
renumber. 
              Paul Andersen:  Question for John Sweeting?  
              Joe Provo:  Just clarification of that interpretation of
4.10.  
              Paul Andersen:  Why don't you show him the question and he
can give you clarification.  Go to the next microphone.  
              Owen DeLong:  Owen DeLong, ARIN AC, policy shepherd.  I
support the policy as written.  It was kind of silly when we put the 28
in in the first place.  But it looked like things may go in a way that
would make that desirable, especially when people were pushing us down
from the /8 that we wanted to reserve for this to a /10.  So we did what
made sense at the time.  It no longer makes sense. 
              Moving to 24 is goodness.  More importantly, I think the
/21 cap on recurrent issuance is a good thing.  And I'd like to see that
implemented in the policy.  So, yeah.  
              Paul Andersen:  We'll let John Sweeting jump in here.  
              John Sweeting:  John Sweeting, clarification.  We've been
talking about giving out 28s.  We cannot give out 28s by policy.  Our
minimum assignment size is a /24.  That's the problem.  
              Correct.  If they asked for a 28, we give them a 24
because we have to by policy.  
              Unidentified Person:  By implementation, not by policy. 
The policy says you give out 28s.  
              John Sweeting:  I believe it's policy that says minimum
allocation or assignment is /24. 
              Paul Andersen:  All right.  We're going to switch to the
NRPM.  
              Next microphone, please.  
              Andrew Dul:  Andrew Dul, policy author, ARIN AC.  I
support this draft as written now.  I would also support the removal of
the six-month requirement in lieu of the changes to hook this to
multiple discrete networks as we discussed earlier today, which would
allow practically an organization to get eight of these at one time at
the beginning sparsely allocated.  
              That seems okay to me.  I'm okay if we leave the time
restriction in.  The reason we have 21 is it's eight distinct /24s.  
              I thought four was too small.  And the statistics that
John Sweeting provided us earlier about the number of multiple discrete
networks within an average multiple discrete network larger organization
of I think he said it was seven fits nicely with the eight number of a
/24, /21 of eight /24s.  
              Paul Andersen:  Okay.  Thank you for that.  I guess
assuming that we're referring, of course, to either 4.3.2 or 4.2.1.5,
that would say that the minimum assignment by policy is a /24, I think
that's what John Sweeting was referring to.  
              John Curran has a point. 
              John Curran:  If I could speak.  Sorry, I missed earlier
someone was referencing 4.10, the IPv6 deployment block.  
              You have a policy that says that we could allocate down to
a /28.  But it's a max we can allocate in size is /24.  
              As a practical basis, as noted in this request, in this
policy change, both ARIN's tools are problematic if we allocate smaller
than 24.  And there's two other sections in NRPM in Section 4, one for
ISPs and one for v4, that provide a /24 minimum allocation.  
              And it's not clear that the language in 4.10 is
sufficiently strong to overcome the minimums elsewhere in Section 4.  
              So it's rather problematic if you actually do want us to
allocate a 28 and do lots of those to lots of people and not internally
treat it as a 24, which is what we've been doing.  
              Therefore, this policy also changes something in a way
that avoids a number of sinkholes, because it raises the minimum
allocation to match what our practical internal usage is of /24.  
              We see the policy says 28.  We have been treating it as
24.  And we have basis in other parts of NRPM that says a 24 is what you
want for IPv4 anyway.  
              Does that clarify, Andrew?  
              Andrew Dul:  I understand.  I disagree with one of your
statements.  
              Paul Andersen:  For the remote participants, Andrew is
just stating he disagreed with one of the statements.  So it be said.  
              We're going to close the microphone shortly because we're
getting tight on time.  So front microphone.  
              David Farmer:  David Farmer, University of Minnesota, ARIN
AC. It is technically possible for us to use 28s.  
              The thing is we need to look at who is using this policy
chunk.  It's new entrants that need this chunk in order to -- a v4 in
order to do their v6.  They are not the most sophisticated people that
ARIN deals with.  
              Making it this hard -- 28s are possible but they're really
hard.  This makes it -- using 28s makes it too hard for the
unsophisticated users that are using this policy.  
              24 cleans that -- the 24 for max and min cleans that up,
makes it easy to use.  That's the intent of this is to make it easy to
get a chunk of v4 so you can do v6.  We screwed up when we added the 28
into it.  It's just plain and simple.  We're not perfect. 
              Paul Andersen:  Okay.  And John, like if I understand
correctly, because I want to make sure we talked about possibilities. 
There's obviously the routability, which ARIN cannot guarantee, and that
is what it is.
              But there's also the problem that the back end systems
that generate the zone files for DNS deal with the RPKI and just general
registrations currently do not support, even if the policy was lifted,
would require work to allow for /28s and such.  Not saying they couldn't
be changed but there would be significant work to do that.  
              John Curran:  Right. 
              Paul Andersen:  Those are two separate problems of the
usability of a /28 versus the usability for us to allocate /28.  I
wanted to clarify those two policies.  
              Front microphone.  
              Michael Casadevall:   Michael Casadevall, NARALO.  I'm a
little bit concerned that in cases where a 28 would suffice we'd be
issuing a 24.  
              You can fit -- if my math is right -- eight /28s in a 24. 
We're giving up a lot of address space for what we've already sparsely
populated.  
              I think it's worth the discussion, maybe not right now, to
look at making the back end system and the policy be able to issue
smaller for /28 for those customers that can use it.  
              I'm okay with the default being a /24, but for people that
know what they're getting into, let's not waste IP space unnecessarily,
especially since there isn't more coming. 
              Paul Andersen:  Could be good table topic for tomorrow on
the ability for what's the usefulness of those allocations.  
              We're going to close the microphone after this speaker. 
So please approach the microphone.  
              Joe Provo: Proxying, Brian Jones, Virginia Tech.  Should
the 80 percent utilized threshold be raised since the allocation size is
being raised to a 24 in this policy?  
              And also I support the policy 2019-3 as written. 
              Paul Andersen:  Okay.  Thank you for that.  You wanted to
add one comment?  
              Alicia Trotman:  I love the energy and feedback I got
today.  On PPML I got one response.  I want to see that energy in the
fingers.  Yes. 
              Paul Andersen:  Microphones are closed.  Final comment.  
              Joe Provo: Jason Schiller, Google, ARIN ASO AC, objects to
the conflict existing as 4.10 is neither 4.2 ISP space, nor 4.3 end user
space.  So he doesn't see the same conflict.  
              Paul Andersen:  Thank you for that comment.  That ends the
input.  Microphones are now closed.  
              Would you like an extra pair of glasses?  You already have
one.  Thank you to our AC for presenting.  That ends our policy today. 
Thank you all.  
              (Applause.) 
              John Curran:  Okay.  So we're coming towards the end of
the day and we have one great presentation before we finish.  
              Our friends, Brenden Kuerbis and Milton Mueller, have done
a study on economic factors affecting IPv6 deployment.  
              I think it's example of some of the information that could
be presented to the ARIN community to illuminate how we're doing in this
world. 
              We talk a lot about IPv6, but we don't talk about what's
actually happening.  Hopefully their study will share some insights and
get people thinking about where we are today.  
              Brenden, go ahead.  
              Brenden Kuerbis:  I'm in the enviable position of being
between you and the beach.  So I will hustle through this and try and
get you out of here as quickly as possible.  
              So thanks to the ARIN Board for the opportunity to present
this work on economic factors affecting IPv6 deployment.  
              This work was sponsored by ICANN's Office of the Chief
Technology Officer.  
              So despite more than a decade of evangelism on behalf of
v6, the Internet community has not yet succeeded in moving the world to
a new networking standard.  
              Technologies like NAT and secondary markets for v4 numbers
have introduced major economic efficiencies that have extended the life
of v4.  Therefore, it's not really correct to call the v4/v6 transition
a migration really; rather, it's a standards competition, and we need to
understand better the dynamics of that competition and its implications
for the future of the Internet.  
              Given this problem, we wanted to research what economic
incentives affect decisions by operators to deploy v6 and what factors
could best explain the observed leves of v6 adoption at the country
level, and how do translation and tunnelling technologies which serve as
a bridge between the incompatible standards alter the economic
incentives to remain with v4 or deploy v6.  
              As an academic, there's an extensive economics literature
on network migration.  When strong network externalities are present,
timing is everything.  Adoption decisions are path dependent and
converges on a common protocol is not reversible as it creates a lot of
inertia and lock-in.  
              So when IPv6 was first developed, there was really no
economic incentive or motivation, rather, to adopt it.  So it was v4,
not v6, which spread like wildfire during the early years.  
              And widespread compatibility across the entire market
raises the cost of switching to a new standard that is not compatible
with the old one.  
              So the proposed dual stack migration model envisioned by
v6 designers had two fatal problems.  One is that it doesn't reduce the
demand for v4 numbers.  And the other is that v6 deployers take on
additional costs, while those who remain on v4 do not.  
              But some people have said that there's a last mover
advantage because of these problems.  But I'd say that's too
pessimistic.  A last mover advantage would equilibrate on everyone
moving on v4.  
              But fortunately for the transition that's not a correct
view.  Right?  As a factual matter, there are first movers and there are
numerous early movers.  
              On the other hand, though, those decisions seem to be
independent and uncoordinated and almost randomly distributed across AS
operators.  
              So IPv4 address space exhaustion is a constraint on an
operator's growth, the growth in the v4 Internet requires purchase of
increasingly expensive v4 number allocations in the market and ever more
intensive sharing of globally routed v4 numbers.  
              In contrast, v6 numbers are abundant and inexpensive and
deployment opens the door to less constrained growth.  But deployment,
v6 deployment does, however, incur significant initial and ongoing costs
that are caused by the necessity of maintaining compatibility with v4.  
              Because of that need for backwards compatibility, v6
deployment does not immediately eliminate an operator's need for v4
addresses, nor does it eliminate the need to share those addresses.  
              So the key drivers of the deployment game then is an
operator's kind of subjective assessment of the value of network growth
to its business and relative cost of that growth plan that involves
either an IPv6 deployment or one that does not.  
              For a network that does decide to deploy v6, this cost of
growth is a function of the initial cost to deploy; the infrastructure
investments, the coding, the learning.  Most of these are one-off in a
single time period.  Although, for larger networks there can be -- they
can be distributed over time in different parts of the network. 
              Plus the cost of compatibility to maintain backwards
compatibility with the v4 Internet, including NAT translation or
tunneling infrastructure.  And the cost of running a duplicate protocol.
 And the costs of discovering and fixing things that are caused by the
v6 deployment.  
              Plus the negligible cost of v6 numbers.  For the network
that does not deploy v6, the cost of growth is a function of extending
the use of v4 by operating a NAT facilities plus the cost of acquiring
additional addresses in the market.  
              You guys are probably familiar with this.  It's data from
the well-known APNIC measurement system that calculates for each economy
an autonomous system, a percentage of user populations that have the
capability to use v6 or prefer v6 connections.  
              In the aggregate view, the data does not really indicate
that v6 is being ignored, but it also does not indicate that a
technology is following a normal diffusion curve.  
              In many respects, aggregation of all the world's networks
into one graph or trend line is pretty misleading.  For instance, when
you drill down to the regional level, you see cases where more
economically developed regions have higher adoption.  In 2018, the
Americas had stood at about 29 percent.  In Africa, it's about 1
percent.  
              There's even variance between economically developed
regions.  For instance, the same time period Europe was at about
15 percent, about half of North America.  Asia was at about 17 percent. 
And [ASEAN about] 15.  
              To better understand adoption, we collected the average v6
capability measurements from APNIC for 215 economies, across a similar
120-day period in 2015, '16 and '17.  And we validated that data against
Akamai data.  They've also taken v6 measurements and found it to be
strongly correlated.  
              From that data we looked at 90-day smooth averages, and we
identified countries with over 5 percent measured v6 capability in any
one of the three years of the study.  This figure shows these economies
by growth trends that we observed.  The vast majority, or about
80 percent, had no appreciable deployment.  
              That is, they remained at or below 5 percent.  The next
largest group were economies with increasing levels of v6 capability. 
And that was about 12 percent of the countries.  
              These economies were located around the world.  The next
largest group at about 8 percent exhibited plateaus in deployment with
v6 capability stopping at levels anywhere between about 5 and 60 percent
or, actually, 9 and 60 percent.  
              That group included numerous mature European economies as
well as countries in other regions, Australia, Canada, Vietnam, Equador,
Peru.  
              But the most accurate picture of v6 deployment comes from
looking at adoption levels of individual ASes operating in the same
market on a disaggregated basis.  
              This figure here shows v6 deployment for the top four ASes
international market according to the samples collected by the APNIC
system which is a rough proxy for market share, using the same
measurement methodology I spoke of earlier.  
              In the US and New Zealand what appeared to be gradual
country-wide increases revealed to be plateaus for earlier adopters,
which are then joined by new deployments by other operators.  
              Note, in New Zealand, of one of the top four ASes has not
deployed v6 at all.  And the earliest and most extensive deployer is a
mobile operator that has plateaued around 50 percent.  
              This gives you a sense of some of the plateauing
countries.  And again you see some variance between the operators, that
they're not all following the same pattern.  
              For instance, in Belgium, you see there was some
coordinated action between operators with the regulator and three of
them got up to around 75 percent.  Although there still remains one
operator that has no deployment there.  
              In the interests of time we'll skip through this.  So we
next developed kind of an economy level of dataset covering the 2015 to
2017 period looking at macrosocial factors in IPv6 adoption.  This
included APNIC measurements but also world development indicators
published by the World Bank.  
              As well as fixed and broadband wireless, fixed broadband
and wireless market concentration measurements as captured by the
Herfindahl-Hirschman index from Facebook's Inclusive Internet project.  
              Our findings so far are pretty consistent with our
understanding of the economic incentives to adopt v6.  
              We found higher levels of v6 capability are correlated
with greater country level GDP per capita because IPv6 deployment is
costly.  
              Network operators in countries with greater wealth are
more likely to risk money on it.  Examples would be lots of fixed
broadband networks in Western Europe, Japan, United States, Canada.  
              We also found higher country level v6 capability rates
were correlated with lower levels of concentration in wireless and
broadband markets.  
              This is not as straightforward to interpret but it does
seem intuitive.  A market with more players increases the likelihood
that one of the firms will make a random decision to deploy v6.  And in
less concentrated markets it's also more likely to permit new firms with
no legacy infrastructure for whom the cost of v6 deployment is not much
different than the cost of a v4 deployment.  
              So supply of v4 numbers plays a great role in the v4/v6
standards competition.  The prospect of what some engineers called IPv4
runout was one of the main reasons for developing the v6 standard in the
first place.  
              From an economic point, however, those resources don't
just run out; instead, as the supply diminishes, they become
increasingly expensive and consumption patterns adapt to the scarcity
with greater conservation and new forms of substitution.  
              And network operators have adapted to this tighter supply
in two ways.  One by using that and the other adaptation is the
secondary market.  
              Now, the incentives provided by the secondary market have
led to the identification of millions of unused and underutilized v4
numbers by brokers and exchanges.  And we see evidence of that in the
adaptation in the v4 market data -- we see evidence of the adaptation.  
              So reviewing the limited publicly available data that's
out there for pricing, we see the median price per address has doubled
in four years from around eight in 2014 to '17 and 2018.  And as one
would expect the range has narrowed as the market matured and initial
kind of uncertainties about the values of addresses, the value of those
addresses were resolved.  And we corroborated these price trends with
interviews with other address brokers.  
              These you saw this morning.  We'll skip that.  The only
thing I would mention in this is this is total addresses transferred,
this kind of levelling off that we see in the amount of addresses
transferred per year corresponds to the steady rise of prices and
possibly indicates that supplies of untapped v4 numbers, blocks, are no
longer expanding.  Speculation, though.  
              So who is buying these resources?  The answer is cloud
service providers.  So CSPs are a rapidly growing market, as we all
know.  Interviews revealed in terms of the numbers of customers and
interconnected hosts, the cloud networks represent some of the largest
networks ever connected to the Internet.  
              And while this market initially served or mostly served
individual developers, enterprise use of them has grown tremendously
over the last few years.  
              CSPs are buying v4 numbers because enterprise networks are
lagging behind in IPv6 deployment relative to the public provider
networks. 
              One interviewee said that only about 5 to 7 percent of
enterprise network traffic is v6-enabled.  And that assertion can be
corroborated by NIST estimates, Department of Commerce estimates, of
industry v6 deployment.  
              Enterprises are also slower to upgrade applications
currently if they have current revenue from them.  This drives demand
for v4 addresses amongst the cloud providers as each instance of service
that they're providing to these customers may require a globally routed
v4 address.  
              But you have other networks acquiring v4, including the
growing ISPs, such as Charter and Indian Mobile, Reliance Jio, which,
while using v6, still have great demand for v4 given the scale of their
networks and the need to connect to IPv4 hosts.  
              We next modeled how an operator's requirements for a
globally routable v4 addresses over a 15-year period are affected under
two transition cases, both dual stack and conversion, specifically
464XLAT.  In both cases we assumed conservative carrier-grade NAT
configuration values based on equipment provider manuals, RFCs, this
type of information.  
              The model allows us to explore the way that operators need
for v4 addresses is affected by the various subscriber baseline values
and growth rates in those subscribers, as well as the baseline value and
growth of IPv6 capability and operators traffic matrix ratio at their
gateway.  
              This provides insight into how v4 address scarcity might
create some incentives to deploy v6.  
              Now, as we discussed the model, it's important to keep in
mind that the reasonableness of the assumptions regarding growth in
network size and the shift in the v6 ratio vary obviously across each of
the 60,000-plus ASes.  Operator diversity means that any number of
outcomes could be possible.  
              Decisions regarding v4 address acquisition and v6
deployment take place on an individual operator basis and will reflect
that diversity and conditions and incentives. 
              The best we can do is show some various scenarios and
discuss their implications for the transition.  
              So here we're showing a large mobile network with a fast
subscriber growth rate of optimistic 15 percent per year, coupled with a
slower 5 percent annual shift in the traffic ratio towards v6.  The
levels of v6 traffic are assumed to start around 44 percent, which is
the number observed in the United States.  
              These assumptions produce an inflection point after about
10 years where the network's technical requirements for v4 addresses
starts to decline.  
              This happens when the traffic ratio is near 74 percent v6.
 If the subscriber growth rate were lower, then the inflection point
occurs earlier, that is, it shifts to the left on the X axis at a lower
v6/v4 traffic ratio.  
              Now, the model is also sensitive to the specific patterns
of growth that I had mentioned.  Growth could be either linear,
accelerating, plateauing, follow an S-curve.  
              So, for example, if the subscriber growth rate slows down
and it starts to plateau after about seven or eight years and the IPv6
traffic ratio follows a more rapid S-curve in growth pattern, the
operator's need for v4 numbers starts to decline after only four years
and approaches zero after 15.  
              However, a different set of assumptions for a different
type of network tells a very different story.  This figure shows a small
enterprise network that only has 10,000 users and grows only 2 percent a
year.  
              The traffic ratio shifts towards IPv6 at the linear rate
of 4 percent a year.  But since the enterprise is located in a older
legacy environment, software and hardware environment, the starting
point for v6 traffic ratio is set at 22 percent rather than 44.  
              In this case, the implementation of v6 doesn't do anything
for the operator.  Its v4 numbers increase modestly, whether or not it
implements v6.  So the additional expenses for deploying it really
wouldn't reduce its demand for v4 addresses by a worthwhile amount.  
              And while its v4 number requirements would also increase
without v6, the small scale of the network means that the additional
numbers are needed, only about a thousand to 1500, would not be that
expensive or hard to come by.  
              At worst, NAT could be tweaked to stretch their address
assignments further.  In general, for smaller-scale networks, the gains
from v6 deployment don't appear to justify the expenses.  For such
networks, it makes sense to continue to extend v4.  
              Not until the market value of those addresses held by the
network exceeds the enterprises cost of transitioning to v6 would there
really be an economic incentive for them to change.  
              However, not all enterprises own their v4 addresses.  And
in those cases there may be pressures to shift from an upstream service
provider.  
              So we've seen a scenario where we had a growing mobile
operator that may be in a position to sell surplus v4 addresses back
into the secondary market.  But it's also possible to posit scenarios
where large providers might want to hang on to their v4 numbers.  
              This figure represents assumptions about a major cloud
service provider.  It assumes 60 million subscribers to start with an
S-curve growth trajectory in their numbers over 15 years.  The v6
traffic ratio is assumed to grow rapidly at first but then plateau at
around 70 percent.  
              We have also assumed a lower starting point for the v6
capability traffic ratio because CSPs interact with a lot of enterprise
networks likely to have lower v6 deployment rates.  So the models show
the v4 requirements for CSP declining steadily for five years while the
traffic ratio shift rate exceeds the subscriber growth rate.  
              As the shift rate levels off, however, the requirement for
v4 numbers starts to increase again as the subscriber growth continues. 

              Thus, some operators might, despite experiencing increases
in v6 traffic and declines in their immediate v4 requirements, continue
to hold onto v4 resources, in the face of uncertainty about future v6
traffic ratio and v4 prices.  
              While the traffic ratios are operator-specific, such a
scenario definitely could occur given numerous economies that are
exhibiting plateauing growth currently.  
              So, in conclusion, there's good news and bad news in our
findings for IPv6.  The good news is that v6 is unlikely to be what's
called standards orphan.  
              For network operators that need to grow, particularly
mobile networks where the software and hardware ecosystem is mostly
converted, v6 deployment can make economic sense.  It mitigates major
constraints on growth and can provide a path out of the operational
complexities and costs of large scale NAT.  
              Our modeling of the dual stack and conversion method shows
that for a fast-growing network, v6 deployment contain, but not
immediately eliminate, the requirement for more v4 number resources.  
              The key variable is how quickly that traffic ratio shifts
towards v6 and the rising price of v4 numbers provides an additional
stimulus to deploy.  
              The bad news is that the need for deployers to maintain
backwards compatibility with nondeployers eliminates many of the network
effects that would create pressure to convert to v6.  
              Additional bad news is that many enterprise networks don't
need to grow much and/or maybe still lodged in slower-moving hardware
and software systems tied to v4.  
              Another issue that emerged from our modeling exercise was
that once the IPv6-only traffic ratio among v6 deployers reaches a
certain level, their v4 address requirements start to decline.  
              Now, these operators in theory could therefore release v4
addresses into the market and that would alleviate the shortages and
facilitate continued low levels of growth for legacy v4 networks. 
              So given this complexity it's hard to -- and the
independent, the number of independent actors and the different
scenarios that they're facing, it's hard to posit scenarios that lead to
kind of global convergence on v6 within 20 years.  
              And it makes sense to consider the implications of what a
mixed world means.  Right?  Including the architectural, economic and
policy implications of a mixed world.  Thanks.  
              (Applause.) 
              John Curran:  Okay.  Any questions?  We just learned we're
going to be looking at v4 for a while.  Lots of opportunity for new
policies.  
              (Laughter.) 
              Any questions?  Last chance.  It is kind of harsh being
between here and the beach.  
              Thank you for coming, Brenden.  Thank you for the study.  
              (Applause.) 
              Okay.  With that, I will now do the closing announcements
and adjourn us for the evening.  
              So thank you for our sponsors, our two sponsors, C&W
Business and Google, network and webcast sponsors.  Big round of
applause.  
              (Applause.) 
              Meeting sponsor, Addrex.  And our silver sponsor,
IPv4Mall.  
              (Applause.) 
              Okay.  We have a women's networking reception.  It's in
the Needham's ballroom.  It's actually starting now and going about the
same time.  So Needham's Ballroom 3 if you're interested in that.  
              Tonight's social is at Copacabana.  There are buses to get
there.  Your badge or your social badge, which is inside, will get you
in.  
              You must have a badge to get on the bus.  You must have a
badge to get in.  So bring your badge.  Either badge will be fine.  
              Shuttles run from this level, the elevators, the hotel
lobby, it's a level above us, you have to come down to the ground level.
 
              If you go out the doors, turn right in the circle to the
lower level, just walk out the door to that circle, that's where the
buses are going to be.  6:45, 7:00, 7:15.  
              Return shuttles will begin at 8:30.  Barbados experience:
buffet, favorites, beach games and wonderful views.  So it should be a
wonderful social.  
              Reminders.  Tomorrow, breakfast at 8:00 next door.  The
meeting will start here at 9.00 a.m. 
              Thank you.  Our meeting materials are all online if you
want to know what's set up for tomorrow.  
              Thank you and that's it.  Look forward to seeing everyone
at the social tonight.  Take care.  Goodbye.  
              (Applause.) 
(Meeting Adjourned at 4:35 PM.)