ARIN 43 Public Policy and Members Meeting
Day 2, 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 9, 2019, 9:00 AM
              -oOo-
              
PUBLIC POLICY MEETING, DAY 2 - OPENING ANNOUNCEMENTS 
              John Curran:  Good morning.  If people will come in and be
seated, we'll get started.  
              Welcome to the second day of ARIN 43 in Barbados.  I'm John
Curran, president and CEO.  We have a pretty full day today I'm going to
talk about.  Let me start right in.  
              We have remote participants, as a reminder.  I'd like to
welcome those who have come back in remotely.  Everyone has access to the
materials.  It's in your online site and it's in your app if you're using
the application for your phone.  You can participate in the virtual
microphone and consensus process.  So glad to have you.  Welcome remote
participants back as well.  
              Get the meeting app if you don't have it.  The meeting app has
a great schedule of events, lets you find your way around the hotel, lets
you find the attendee list.  Feel free to download it, and it's useful at
times.  
              I'd like to thank our sponsors -- network sponsor, C&W
Business, and webcast sponsor, Google.  
              (Applause.) 
              I'd also like to thank our platinum meeting sponsor, Addrex,
and silver sponsor, IPv4Mall.  
              (Applause.) 
              So, we're going to have discussions today in the morning about
some policies.  These policies are part of our Policy Development Process. 
The chair of the Board of Trustees will moderate the discussion and make
sure everyone has a chance to be heard.  
              That means you should be respectful.  Pay attention to the
courtesies in your program guide.  And it's just important when you go to
the mic, speak clearly.  Speak slowly for the sake of the live transcript
we're building.  State your name, affiliation.  That will help everyone and
let us have a good record of the meeting.  
              Today's agenda.  We're going to hear global reports in the
morning from APNIC and AFRINIC.  We're going to have RPKI Services Update,
which includes an update from the UPEN folks that did a study on issues with
deployment in North America.  And then I'll give a report from ARIN about
our ongoing risk assessment.  
              We have ASO AC Update.  We have the IANA Review Committee
Update.  We'll give a Transfers Report about transfers in the region and
inter-region.  We'll have a LACNIC report, and we'll start in the policy
block and handle ARIN 2019-4: Interregional IPv4 Resource Transfers.  
              We also have a number of others on the agenda.  We have a
discussion of potential Waiting List policy actions that are being
considered.  
              We have several draft policies that are not recommended draft
but are still important discussions.  We have global reports from RIPE and
the IANA PTI.  And we have a Caribbean update.  You'll hear from our
Government Affairs and Public Policy team.  We'll give you an update on our
software development and open microphone.  
              It's going to be a very busy day.  We're going to go straight
from now until 10:30, which is our first break.  
              Again, there's a policy discussion room around the corner.  If
you want to talk about ideas, grab a member, people who have similar ideas,
and go over there and work something out.  
              This is how we make progress in our policies.  RSD help desk
remains open outside, available 8 AM to 5 PM.  
              And at the head table, same head table:  Paul Andersen, our
Board chair; Bill Sandiford, our Board vice chair; Tina, our AC chair; and
Leif, our AC vice chair.  
              With that, I'd like to start with our first presentation.  And
it will be the APNIC.  Come on up, Tony Smith.  
GLOBAL REPORTS: APNIC
              Tony Smith:  First up for the day, so hopefully this will help
wake you up from last night.  
              Okay, APNIC update.  Let's get underway.  So the APNIC region,
for those who are not familiar, we cover 56 economies in the Asia-Pacific
region, as far west as Afghanistan, all the way through to remote Pacific
Islands in the east.  
              It's a very big region, multiple time zones, multiple
cultures, very diverse.  
              Our membership has continued to grow over the years.  We are
now -- on this slide here, you can see we're just under 16,000 end of 2018. 
We're now just over 16,000.  
              We have national Internet registries within our region.  Some
of those predate APNIC, which is sort of unique amongst the RIRs.  
              So in terms of direct membership, it's around 7,000, and
membership through the NIRs is around 8,000, all up around 15 at the end of
last year, but it's about 16 now. 
              In terms of the delegation statistics, as you can see on the
screen here, everything is still to an extent moving up and to the right. 
We had a dip in 2017 across most of our metrics in terms of delegations. 
              V4, as you can see, has flattened off a bit, which is
interesting.  V6 continues to rise.  And of course v4 transfers continue to
rise -- not as many as in the ARIN region, but transfers are still a big
deal in the APNIC region as well.  
              In terms of the resource holding across our members, the good
news here, there's probably a stack.  The highlight is the v6 number
continues to grow.  62 percent of our members have a v6 allocation, which is
great.  And we continue to work to make sure that they actually announce
those allocations.  
              The survey, just want to touch on this quite quickly.  We do a
survey every two years of our membership base and the community to find out
what they think of us, how we're going, how we're performing, but also to
get information from them on what we can do to serve them better and what
are their challenges.  
              We had a really good response last year with more than 1200
responses.  A third of those were in languages other than English, which was
great.  
              The survey results themselves, I'm not going to go through
them today because obviously it would take forever.  But if you go to that
link, APNIC.net/survey, you'll find all the survey materials there in the
reports.  
              There's some interesting stuff in there.  Probably two of the
biggest findings -- well, a good finding was that the members actually were
pretty pleased with our performance, which was nice.  
              But more importantly, we found out things that they want us to
continue to invest in.  Security and training were two of those areas.  And
I'll talk a little bit more about what we're doing in those areas in a
moment.  
              Policy.  So this is probably the most boring slide of my whole
deck, but it's actually got the most information in it that you'll probably
be interested in.  
              So of the proposals that have gone ahead to the members in the
past year and a bit, probably the ones to talk about are prop-125, which was
validation of the abuse-mailbox and other IRT emails.  I note that this is a
proposal -- a similar proposal has been put forth in the ARIN region.  
              This reached consensus at APNIC 46.  We're now in the process
of implementation.  That will happen over two phases to occur by the end of
this year.  But most recently, at Daejeon in Korea, at our most recent
meeting this year, three policies reached consensus, but two that are
probably of the most interest to you is that our minimum allocation size
from the final /8, 103/8, has been reduced to a /23.  Used to be a /22.  
              And alongside that, we maintain a Waiting List where all of
our recovered IPv4 space is put.  And that Waiting List in the APNIC region
can request a /22, a maximum /22 from that Waiting List.  
              And what that -- that Waiting List has been abolished -- well,
not yet.  It will.  The implementation period for that policy will be within
three months as per the PDP.  However, the maximum delegation for 103/8 has
been immediate, so that's enforced now.  
              What this means is that in the past an APNIC member could have
one allocation from the final /8 and one allocation from the -- sorry, to a
maximum of /22 from both the final /8 and from the Waiting List. 
              With the Waiting List now going to be abolished, it will mean
that they can only get a -- one allocation from the final /8 of /23.  Most
of our existing members have actually done that.  So realistically speaking,
this is mostly now new members would get that allocation.  
              We do a lot of work in the region, a lot of external
engagements.  I'm not going to go through this slide.  I'll talk through
them in a moment.  We try to spread our activities across four sub-regions,
which are South Asia, Southeast Asia, East Asia and Oceania, in a number of
areas.  
              Training is a big one.  We do a lot of training in the region,
both face to face and actually online as well.  Training is a big deal for
our members.  It's something that they've requested constantly in our
surveys.  It's something they want us to continue.  So we try to get around
the region and try to provide as much training as we possibly can, as
humanly possible with our resources.  
              We also participate quite a lot in the technical community
obviously within our region.  We participated in 21 NOG events this year.  I
think there's -- from memory I think there's about 17 or 18 NOGs in our
region.  So they keep us busy.  
              We also invest our staff time providing advice and also
sponsoring equipment for root servers and IXPs in the region.  
              We also have, this year have, been spending a bit more time
building a closer relationship with the research and education community. 
And we did some training for the first time at the APAN meetings and have
been working closely with them. 
              On the security front, so when we say "security" for APNIC, it
means that most of our work is done in forms of training and advice and
technical assistance that we provide.  
              So we also have made sure that we've been including more
security content in our conferences.  We've done that in partnership with
FIRST, which is the Forum for Instance Response Teams.  For the past few
years, we've made sure that they hold a one-day conference as part of the
APNIC conference or the APRICOT conference.  
              That content is now being embedded into the main program,
which is good.  We want to make sure our members are exposed to that
information and are getting that input. 
              But at the same time we are doing a lot of training in the
region.  We're contributing to the establishment of new CERTs in the region.
 Tonga was the first one that we had a hand in providing advice and
technical assistance with.  Papua New Guinea and Vanuatu were the other two
last year.  
              We also did a lot of work in PNG ahead of APEC meeting, which
was held there last year, in terms of providing training and technical
assistance to make sure that they felt ready for that meeting.  
              And security continues to be a big focus for us.  We continue
to invest in it, and it's something that our members want us to keep doing. 

              The conferences.  I've mentioned them a few times.  The last
two were -- APNIC 46 was in Nouméa, New Caledonia, an island paradise not
unfamiliar to this one.  And the last one was in Daejeon, South Korea, which
was much colder, earlier this year. 
              The attendance has tended to be strong, continued to be strong
actually at the conferences.  Our remote participation numbers continue to
rise as well, which is a good thing.  That's something we've tried hard to
grow because we obviously understand that our members -- it's a big region
and they can't travel to all of our conferences.  
              RPKI.  I probably won't go into too much detail on this slide
apart from the fact just to say that RPKI continues to be a focus for APNIC.
 It's something which we'll be doing a lot more on this year in terms of
training, education and encouraging our members to basically certify their
resources and get their ROAs. 
              We've had a campaign going for a few years called Ready to
ROA, with the old tiger down at the bottom there.  But if you'll see from
our numbers, it is growing in our region, which is good, albeit from a low
base.  And we want that to continue to grow, and we're already seeing that
this year.  So it's something that it's going to be a big focus for us this
year and into the future.  
              I mentioned training before.  APNIC Academy, I just want to
call this out.  This is an online learning portal where you can do
self-paced training.  
              We relaunched it in August 2018 with all HTML5.  If you
haven't had a look at it and you're interested, there's plenty of courses on
there.  It's free.  It's self-paced.  There's a mix of technical courses,
also a policy PDP course, if you'd like to learn about the APNIC PDP.  
              We've had a number of people enroll, a good number.  1500 last
year.  There's also virtual labs there where people can go and test out what
they've learned on some virtual labs across different vendor equipment.  And
new courses are coming soon.  
              So this is another one of our investments that came via
feedback from the APNIC survey, where our members were telling us that they
needed to have access to online training as well as face-to-face and be able
to do it in their own time, which is the reason for the academy.  
              The blog.  I'd like to just quickly mention the blogs.  It's
close to my heart.  We started the blog in August 2014 as a way to better
communicate APNIC's announcements.  But it also -- one of the other main
reasons why we started it was to make sure that we provided a place for the
community to share its news and reviews because there wasn't really a place
for that to happen.  
              And it has been a raging success.  We've been extremely happy
with it.  We publish every day apart from weekends.  
              We have a mix of posts that are from APNIC and from the
community, around 50 percent from the community.  And when I say the
numbering community, I don't just mean the APNIC community, but globally.  
              We have authors from all around the world.  If you haven't
been to the blog before, I recommend you go and have a look.  I'm sure there
will be something there that takes your interest.  
              And if you have story ideas or anything you'd like to share,
then get in touch because, as I mentioned, this is -- we still see this as a
global resource rather than just a Asia-Pacific APNIC resource.  
              Finally to touch on the foundation.  We established the
foundation two years ago.  As I mentioned before with our training, we have
a lot of demand for training, and we can't necessarily meet that demand for
training through member funds and through our own resources. 
              So the foundation was established to help us increase our
development activities without having to rely on our member funds.  
              There are two staff who have been seconded to the foundation
from APNIC, which is Duncan Macintosh and Sylvia Cadena.  The Board was
appointed last year.  We have appointed two new members, Michael Malone and
Danish Lakhani.  
              We now have a full Board -- actually not a full Board; we've
still got spaces for two more.  But the first AGM was held last year, and
the second one is coming up.  
              It's been a success so far.  The foundation raised over a
million dollars Australian in its first year for projects, and we're hoping
to continue that success to help us fund activities that we're doing.  
              Most of the activities so far that have been funded have been
in the Pacific, which is great.  But we need to continue this to make sure
that we're meeting the demand for the training and development activities in
our region.  
              And the last thing I wanted to say was join us.  Our next
conference will be in Chiang Mai in Thailand in September.  The dates there,
the 5th through the 12th.  The actual conference week or conference days are
the 10th through the 12th of September.  Chiang Mai is a beautiful place, as
you can see -- lots of lovely temples, great food, elephants, all sorts of
good stuff.  
              And you can also go to a conference as well and talk about
Internet numbering stuff.  And you can fit that alongside the rest of it.  
              But please do come along.  We'd love to see you there.  It
should be a great conference.  And that's all for me.  Thank you.  
              (Applause.) 
              John Curran:  Any questions for Tony?  
              (No response.)
              Thank you very much.  Next up we'll have the AFRINIC report,
and I believe Patrisse is -- very nice.  
GLOBAL REPORTS: AFRINIC 
              Patrisse Deesse:  Good morning.  Happy to be here.  I'll give
you a quick update on AFRINIC region.  A small short intro, service region. 
We're the fifth RIR that was created in 2005.  It's headquarters in
Mauritius.  
              We're serving 55 economies in Africa and the Indian Ocean
region.  We have just about 50 dedicated staff with a couple of them working
remotely.  
              And it is believed that this might increase further in order
to cater for the needs of the -- the growing needs of the region.  
              Quick look at the membership evolution.  That's growing, as
you can see.  Not as much as in other regions, but we do have our own
growth, which is part of our own reality.  And we do anticipate the growth
to continue in the foreseeable future.  
              Quick look at the graphs with the IP distributions.  You can
see it's per region, actually, it's per the countries.  And South Africa
seems to be taking the large chunk of it, especially in the IPv6.  And the
other continents, the other part of continent is fairly equally distributed.
 
              We are the last one to be hitting the exhaustion.  We are
approaching that very fast, and we only got to about .4 of a /8 remaining. 
And we're about just over 4 million /32 before we hit the last /11.  And
then we hit the softlanding phase two.  
              So that is -- given the current rate of release of IP
addresses and demand, we should be getting there probably in the third or
fourth quarter of this year.  
              Couple of initiatives.  We've adopted the AFRINIC IRR
following RIPE NCC's decision.  And it's working quite well.  And at the
same time, we implemented the Lame Delegation Policy, which is working well.
 And there's been a decrease in the number of lame delegations over the past
month, from 40,000 to 13,000 by the end of 2018. Seems to be working quite
well.  
              Quick look at the policies, which are at different stages of
the process.  We've got a couple of them which has been completed and
implemented.  And we've got a meeting coming up in two months' time.  And
there's going to be quite some excitement having to deal with those
policies.  
              There's quite a number of them, as you can see, still under
discussions, which hopefully will be carried through to the next AFRINIC
meeting which will be held in Uganda in June.  
              Still some more policy under discussions, as you can see. 
Hopefully this is really going through the discussions on a Mailing List and
what have you at this very moment.  
              Initiatives.  As part of our commitment to the community, we
conduct a lot of training.  This is a very important aspect of our
participation with building capacity.  For 2018, 700 engineers and managers
were trained in 21 countries.  
              This will continue to be our focus.  And we have also
developed webinars and online training.  And there's slight shift in the
training approach, moving it more towards IPv6 deployment.  
              We've created an IPv6 help desk.  We're having quite a few --
the focus has really shifted to the IPv6 deployment and moving with the
governments and managers of the importance of deploying and actually hand
holding, if you want, the various organizations who are willing to be part
of it.  
              We also have the research and innovation initiative.  We have
got some five RIPE Atlas sponsored and deployed.  We have conducted a couple
of measurement workshops, including an academic workshop at AFRICOMM.  And
this continues to increase in importance as well and become a popular
initiative which we have created.  
              We have the FIRE program, which is probably equivalent to what
APNIC has got.  It's actually -- the aim is to provide some assistance to
the community members who are willing to start projects but do not have the
funding.  
              So far in 2018 we've supported five projects, to the total of
31,500, bearing in mind that some of those funds are internally generated. 
And also we get funding from outside donors like IDRC and other generous
organizations.  
              It's been a very popular program, and it's really attracted a
lot of attention on the region.  
              As I have mentioned earlier, our next meeting is in Kampala,
Uganda, from the 9th to the 21st of June.  It's actually the AIS meeting,
which is a combined meeting with many stakeholders and partners like AFNOG
and older Internet-related organizations.  It's quite interesting sessions,
and we're hoping to see all of you there.  
              Thank you very much.  And that is all from me.  
              (Applause.) 
              John Curran:  Any questions?  
              (No response.)
              Thank you for coming.  Okay.  At this time we're going to go
into an RPKI Services Update.  I'm going to ask Chris Yoo to come up from
Penn Law, and he's going to give a summary of their recent study, and then
I'm going to give an update on the status, ARIN's analysis and risk
management.  So come on up, Chris.  
RPKI SERVICES UPDATE 
              Chris Yoo:  Thank you for inviting us, John, to present on
this, and frankly for being such a great partner in what has been a very
interesting exercise in terms of how to make the Internet routing more
secure.  
              In a nutshell, for those of you who don't know what RPKI is, I
guess I owe a great thanks to the APNIC presentation immediately before to
highlight that this is something that's growing.  
              This is a way that we can actually make routing more secure. 
As you know, we create routing tables by having BGP partners exchange
routes.  That information becomes basically unauthenticated.  You have to
take the word that the person you're sharing routing information with, that
they're in fact giving you a valid route.  
              There are two technologies that can make that more
authenticatable.  One is BGPsec, which is actually to make sure the entire
step of the route, all of them are validly followed.  
              RPKI is the one, is a much more modest technology, is called
origin validation, which is you can verify that the last step that the route
is pointing to is in fact the authentic location for that website.  
              So there's two steps to RPKI.  The address holder has to sign
-- use a public key given by their RIR to sign a certificate, and that
places in a certificate authority generally hosted by the RIR. 
              And then the ISPs have to access those libraries to do
something called route validation, route origin validation, to actually
screen on the basis of that information.  And every time they get a route,
they should double-check it against the certificate authority and say they
think that UPENN.edu is located here, according to the route being
advertised by my BGP partner.  
              You can then look it up in the library, in the certificate
authority, the certificate library, and make sure in fact that's pointing to
the right address.  And that will make the Internet considerably more
secure.  
              Not a complete solution.  Although, with edge providers
building closer and closer to the customers, if it is a one-hop route, it
can actually be a complete solution. 
              But what we see is a growing interest -- on the other hand,
it's fairly easy to do and would guard certainly against misconfigurations,
but in fact would provide some degree of protection against route hijacks.  
              There's been a bunch of things in the news lately, some very
conspicuous hijacks of Cloudflare's DNS and Amazon's DNS, as Cloudflare has
begun build -- committing to RPKI, beginning to filter on this basis and is
developing their own validator software.  
              Interestingly, though, if they deny the route, it will simply
migrate through transit some other way.  The biggest news are people like
AT&T who are starting to actually filter routes based on RPKI information.  
              Google is starting to do the same.  They're in fact flagging
routes, and they announced later this year they'll begin actively filtering
on it.  
              And what we see is, interestingly, NTT is doing something
else, which is using the certificate library to clean up their IRRs, to
actually look at how they're configured, combining it with other information
to improve the routing quality information.  
              We hear from APNIC that they're in the process of pushing
RPKI.  And David Wishnick, who is my colleague at Penn, just showed me a
posting from the NANOG list yesterday that three African ISPs began
filtering on the basis of RPKI on April 1. 
              So this is a technology that's increasingly growing in
importance.  And one of the things we will talk about more I think when John
talks, operationally this has some implications for you if you want to make
sure your networks flow smoothly and all this works properly.  That's really
the domain of technical experts like yourself.  
              We were actually approached by the National Science Foundation
to solve a particular problem, which is generally RPKI, like many of the
technologies, has been deploying relatively slowly. 
              But the big mystery is it's actually been deploying much more
slowly in the ARIN region than it has in other regions.  RIPE has now hit
43 percent of its addresses or have signed certificates.  And you see in the
LACNIC region it's roughly 23 percent.  
              ARIN is at 4 1/2 percent.  And most interestingly, the others
are growing slowly.  ARIN region has been roughly flat across this time
period in ways that create some concerns.  
              The question is what is -- is there something about what's
going on in the ARIN region that is preventing it from being more widely
deployed?  That's the who's signing.  If you look at ISPs, how many are
filtering, there is an APNIC resource that is actually looking at ISPs and
how many of them are filtering.  
              Again, RIPE, the number of ISPs in the RIPE region is
significantly larger.  And in fact among those who are deploying route
origin validation, 80 percent of them do not include the information from
the ARIN region, including the ARIN TAL.  
              So we were asked by the National Science Foundation to do a
study to investigate whether there are legal barriers that are at play in
ARIN that did not exist in other areas.  
              And in fact one of the -- this is on the basis of several
conversations that people have had at different conferences. 
              And in fact they focused on certain clauses within the
contracts that ARIN asks different users to sign.  As you know, most ARIN
members are resource holders, so you signed an RSA to have the address.  
              There's also something called the Relying Party Agreement
which other people who build on information, who are not themselves address
holders but are building on the information, need to sign.  
              Our methodologies, we've done analysis of the contracts on a
comparative basis with both ARIN's and in other regions.  We've done a broad
scale of interviews with stakeholders and engaged them very actively and
very cooperatively with ARIN.  And I think it's been a positive dynamic and
one that I deeply appreciate.  
              We've been at the last three NANOGs.  We released a report at
the end of the year which we're happy to share with you.  I apologize in
advance.  It's a lawyer-length report -- it's about 30 pages -- as opposed
to a technical-length report.  But it's one of the things that's appropriate
for the subject matter. 
              And to me, I really welcome the opportunity to engage the ARIN
community because this is something of vital importance to the ARIN and all
of its members.  And this is the first presentation, first opportunity we've
had to talk about this here today.  
              Okay.  So if we're going to think about the key issues
involved in this study, we're looking at the Relying Party Agreement,
particularly the fact that other -- the four regions do not in fact require
a Relying Party Agreement, and there's certain clauses within it also that
we're analyzing about the indemnification clause about allocation of
liability.  
              The -- there's a -- talking about how we're going to style the
acceptances -- and this is an area where ARIN has already made changes to
its policies in response to what we've learned through the study.  
              And a possibility of another way to managing liability is the
-- and this is a topic which is just now beginning, and we'd love to get the
feedback from the community -- is whether we should separate the RPKI
function from the numbering functions provided by ARIN and create another
entity to handle that.  
              There's another provision in the RPA called the prohibited
conduct clause, which we'll explain, that causes some problems.  
              There are other vectors for possible diffusion beyond law
involving procurement policies.  We'll talk about best practices because
part of this is about implementation, not just liability, and that's where
this is going to affect everyone in this room.  
              And there's a series of other smaller recommendations which
are mentioned in the report, which I'll just flag for you.  
              So starting at the beginning.  So as of now, the primarily
most widely used validator software -- this is the thing that ISPs run that
accesses the library and determines which routes are valid and invalid.  To
get to the library, you need to access something called the Trust Anchor
Locator, or the TAL, which tells you where the library is located for the
five RIRs.  
              As of right now, the leading validator software is shipped
with four TALs preloaded, but not ARIN's.  And this is one of the primary
reasons that 80 percent of the people who are validating routes do not have
ARIN's TAL.  
              What's interesting is the reason it's not distributed is, by
policy, ARIN requires that everyone who wants to access the TAL go to ARIN's
website and click through to get access.  
              And the reason that is, is there's an aspect of US law that
makes it much stronger to say that by clicking through, you create a
contractual acceptance of the terms and conditions of the access to the ARIN
TAL.  
              And because that is a different step that is not required by
other RIRs, it makes it more complicated -- it leads the validator software
distributors to believe that they cannot distribute their software with a
TAL preloaded.  
              What's interesting is:  Why is that?  There are aspects of
American law about why we would want to handle this through a contract as
opposed to through general principles of law of negligence liability.  
              But it's interesting, as a matter of contract formation, the
contract is much more likely to be found and found valid if someone clicks,
actively clicks on something. 
              There is precedent that if you put terms and conditions nearby
or if the customer, the person is aware of it, the US courts have found
people bound by those terms.  
              But that's not entirely clear and it does create some risk. 
And there is a much stronger authority that says if the terms and conditions
are in the visual field of the person who is accessing the resource at the
time they accept the resource, then it's more likely to be found to be a
binding contract.  
              So we actually analyzed all the alternatives.  There are
people in the community who would like to abolish the RPA altogether.  I
suppose another option is to keep the RPA unchanged.  
              And a third option is to keep the RPA but to make some
modifications, and particularly focusing -- the primary focus we'll
initially focus on is the indemnification clause, which requires whoever is
accessing the resource, if any legal problems or any liability happens, they
have to cover any liability or money that ARIN has to pay as damages.  
              So in terms of dropping the RPA, this is a serious proposal
pushed by a number of people in the community.  It has some advantages.  
              If you have no contract at all, it would promote the widest
possible distribution of the TAL because it's very easy to preload it in all
the software.  
              It has some downsides.  As we said a minute ago, it does
create uncertainty as to whether the contractual terms will be binding.  In
the absence of contractual terms, you go to general principles of negligence
under US law, which are quite uncertain.  
              It's hard -- they work functionally pretty well, but there is
overhanging risk and uncertainty that exists that is greater than under
contract law.  
              And the nice thing, we usually handle these things is through
some sort of warranties in the contract.  You represent what the product
does, and you can actually allocate risk explicitly instead of after the
fact by a court.  
              And this does take into fact that the US environment is much
more litigious than other environments, and that partly explains the
differences in policy. 
              The other alternative that I'll talk about briefly is it is
conceivable that ARIN could keep the existing RPA unchanged with blanket
indemnification.  
              Our analysis suggests that that would be inappropriate,
because if you -- if you as a relying party are forced to indemnify ARIN
against any liability, any problems that come up, that could include
indemnifying them against problems that fell within ARIN's responsibility.  
              And a general principle here is everyone should be responsible
for the things they control.  You should not be held responsible for things
outside of your control.  
              And to ARIN's credit, I think in our conversations with them,
they've recognized that they probably need to -- they're open to rethinking
this provision and is part of their active discussions to try to find out
exactly how that provision and that liability should be reallocated.  
              And there's where the devil in the details come, when we start
to change that, finding that proper allocation becomes much more difficult. 
              The other alternative is to keep the RPA but instead of an
indemnification where the relying parties agree to compensate ARIN for its
liability.  The way we handle it in many areas of software is you sell the
software as is, like you sell a used car.  No warranties.  You make no
representations, and everyone understands they take it on their own risk.  
              This is how we do open source.  It's how we do a large number
of software distributions of different kinds.  
              And in fact we did this partly by comparing it to the policies
of the other RIRs in addition to other types of software and to see how it's
fared under those regimes.  
              And in the other possibility that we talked about in the
community is, if you download the validator software from RIPE, who is the
primary provider of this now -- although there's another one by Dragon
Software that's not really properly supported at this time -- it's
interesting, generally you're going to have to click through some form of
acceptance of that software.  
              You can also configure that so that you're accepting the ARIN
TAL contract at the same time.  And this is a functionality which ARIN has
already agreed to change its policies to support, and I think to much of the
credit of the organization and how this discourse has gone.  
              But that would allow them to get the acceptance of the
contract done.  The question is what are the terms of the contract are you
accepting, and can we shift from an indemnification clause to an as-is
disclaimer of warranties.  
              So we did a very -- an analysis comparing ARIN's policies to
the other RIRs.  ARIN does include a disclaimer of warranties, but they also
include a provision requiring relying parties to indemnify it against any
losses, but also giving them a duty to defend and hold harmless, which means
that they have to pay for the lawyers and litigate -- the relying party has
to litigate through it.  
              And it also applies to actions taken by not only the relying
party but downstream users of the relying party who were actually not part
of this contract.  
              I understand the reasons why this was put in, but if you
compare it to the others, APNIC -- if you look at all the others, they have
no explicit agreement.  
              If you look at AFRINIC and LACNIC at the back, they actually
have no relevant terms and conditions whatsoever.  RIPE NCC has a disclaimer
of warranties but no mention of any indemnification or hold harmless or duty
to defend. 
              And APNIC has no agreement, but their term indemnifications do
mention indemnification but do not talk about a duty to defend or hold
harmless.  
              So ARIN does have policies or contractual terms here that
differ somewhat from the existing RIRs, and they differ in the fact that
they have an RPA.  
              So this led us to really seriously consider the approach taken
in RIPE where they're actually seeing broader scale distribution of whether
a disclaimer of warranties would be sufficient to protect ARIN from
liability, in much the same way ARIN seeks to do based on the
indemnification clause.  
              So as-is disclaimers are widely used.  It would -- I think
would be a fairly good defense against liability for ARIN, because if you
sell something as-is, you can't go back and go after them to say, well, it
didn't function properly. 
              There's an interesting question, though, I think.  There's
somewhat, I would think, procedural risk.  There are ways to get rid of
cases very, very early in the proceedings.  There's sometimes you can get
them later but before trial, and sometimes you have to go all the way to
trial.  
              An as-is disclaimer would probably require ARIN to go through
at least to the middle step of litigation most likely instead of getting rid
of things at the very beginning, which does create not so much overall
liability risk, but some litigation costs inherent in shifting from a
disclaimer -- from an indemnification clause to an as-is disclaimer of
warranties.  
              There's an interesting thing that we studied, which is to try
to see has there been litigation against RIPE under its as-is disclaimer. 
Has there been litigation under other forms of security based on -- that are
governed by as-is disclaimers.  
              And the answer is there really are no cases.  This is sort of
a wonderful Rorschach test that you can make of this as you will.  Some
people would say that the risks are -- this tells you the risks are low. 
Other people would say the risks are unquantifiable because we don't
actually have evidence of how these would come out.  
              I think that deciding things in the face of uncertainty is
something this community will have to directly confront in thinking about
how the benefits of deploying -- of simplifying the deployment of RPKI
against this data we have here which shows that the risk is going to be hard
to quantify and hard to understand.  And the question is what the
significance of the lack of cases really is. 
              I will note that the RSA does include an indemnification
clause, and there is always the caveat that past performance does not
predict future results, in the sense that this information is -- it's the
best information we have about the future, but there's always possibilities
that things are going to vary.  
              There is another radical solution to limiting ARIN's liability
here, which would be to stand up a new company or a new organization that
would hold the RPKI certificates and be responsible for maintaining the
library.  
              There is a debate about whether this would be just for the
ARIN region.  It could possibly include other RIRs or other NICs that are
doing this sort of registration.  
              And there are precedents of standing up organizations of this
in the past.  There are a number of pros.  It would in fact make it more
acceptable for this organization to take on risks and be able to carry it on
for the community. 
              And in fact they would be entirely focused on RPKI
implementation and deployment as opposed to the many responsibilities that
ARIN bears.  
              There is some history here against setting up certainly a
worldwide organization.  I always think that there's nothing more revolting
than to say we had that fight 20 years ago.  It's a very different world, as
we all know now.  That's a conversation worth having again.  
              But the more serious question is standing up an organization
require membership, it requires a certain amount of support, it requires
organizational support beyond financial.  
              You would have to have a Board and some governance.  I always
envisioned this would be organized satellite to meetings like ARIN in the
beginning, but at some point it would have to have its own way to figure out
what its destiny would be.  
              There are actually other ways to facilitate risk management,
the first I mentioned about making people click through when they load the
validator software into accepting the ARIN TAL.  There's another thing that
we're discussing, which is individual contracts don't need to be signed for
every individual instance you're actually setting up.  
              And one of the things that -- the concern that we got from
some of the open source community is they want to be able to just deploy
instances automatically.  
              As it turns out, you don't need a contract every time you put
a new build in.  If it's -- an enterprise as a whole has agreed to it,
basically if you think about it as a site license basis, you do not need
individual acceptances.  We were thinking about ways to facilitate that sort
of agreement to make that work.  
              And in fact there's some things that the RPA could include
inside such as making sure that liability does not include things we call
consequential damages.  So, if your phone call fails and you're paying,
whatever, $50 a month for service, the worst you're out, I'll pay you back
the 50 bucks; I didn't give you the service.  
              You're not liable for the deal that fell through because the
phone call fell typically in the telecom space.  Those are called
consequential damages.  They're almost never honored.  
              Putting that explicitly in the contract would be an effective
way to shed liability.  But our hope is really to stimulate a much broader
conversation in the ARIN and the larger RIR community about the right way to
handle this and the right way to manage risk, because I think there's more
than one reasonable option.  
              We have, you'll see in the report, a belief leaning towards
one particular set of options.  But it's something that we're open to
considering all possibilities.  
              There's some other minor points -- or not minor points, but
other aspects.  One is ARIN's RPA continued something called the prohibited
conduct clause.  It forbids the sharing of RPKI information or information
derived by RPKI in a machine-readable format.  
              Anyone who has deployed security knows that -- looking at
other organizations, other -- four other -- three other RIRs have no
provision.  RIPE prohibits marketing/advertising the use of this for those
types of purposes.  
              What we've learned is that you need reporting and research
anytime you look at new security, and that's best done in machine-readable
format.  And ARIN has already agreed to modify, to waive that for
non-realtime, non-operational uses.  
              What we're seeing now is people want to integrate this with
IRR data for real-time operational uses.  
              In fact, no set of information is perfect.  And taking
multiple sources of information of different provenance, no matter how hard
you try, actually would probably make routing better. 
              We'd like to facilitate that kind of combination in real-time
data, but to do that would require some adjustment to the prohibited conduct
clause.  
              There is another way that you can try to get RPA adopted more
broadly, but we're discovering is the primary obstacle is many operators
just aren't demanding this.  And until it does -- sorry, the customers
aren't demanding that.  Until that happens, the operators are less inclined
to deploy it.  
              If security is important to a customer, they can begin
including it in their calls for proposals.  They can do it into their
contractual terms as a requirement.  And think about this as a
partnership -- we want to work with people who are committed to making the
security environment safer.  
              This is not just governments.  It can be any private company
as well.  And in fact, I think it solves sort of the chicken-and-egg
problems.  And it fits nicely with an initiative being led by ISOC called
MANRS, the Mutually Agreed Norms for Routing Security, which includes
filtering and refers to RPKI specifically as something that partners should
do.  And this clearly has 144 participants.  
              The other thing that we've learned in the process very much in
dialogue with John is that it is important to understand this isn't just a
legal matter; that, in fact, this is an operational matter that every
operator that deploys RPKI has to take into account.  
              No RPKI cache, nothing even at 5.9, 6.9's reliability, there's
always going to be a possibility of some downtime.  And we've seen outages,
admittedly brief, in RIPE, in ARIN, and most recently in AFRINIC.  And
they're going to happen.  
              And like any environment you're in, you need to plan for that
and figure out how you're going to fail over.  And there are best practices
that make it important to say that if the cache becomes unavailable, you
have to fail open, not closed.  If you fail closed, you will disconnect part
of the Internet.  
              So there are things that -- outages that can happen with
misconfigurations on the operator side if they don't adopt best practices. 
The RFCs give that guidance.  There are people who can provide that
information.  
              And in fact there's -- that's the application on the operator
side.  The RIRs will have to take on some additional responsibility,
providing clear information about refresh cycles, updates, uptimes, response
times, all the things that you need to know to operate how to work with an
organization or new service.  
              And, in fact, we really think there needs to be a dialogue
here.  And in fact it's going to put obligations on ARIN to support things
beyond what they did before. 
              The other two small issues we talked about.  There is some
reports -- I mean, government agencies are unable to sign documents that
include indemnification clauses and choice of law clauses.  ARIN has already
indicated its willingness that if there's a legal requirement that the
government agency cannot do that, they will waive those.  And that in fact
is, I think, a helpful reform that's already been implemented and, I think,
is an example of ARIN's cooperation.  
              There is a recommendation, some legacy address holders are
unwilling to sign the -- can't get the services they had before when they
were legacy holders without signing an LRSA.  But if they want additional
services, they have to sign.  
              RPKI is an additional service.  And so in fact their
objections are to other aspects of the LRSA, not the RPKI aspects.  
              RIPE has created something called a non-member services
agreement that decouples these two issues because the broader issues of the
LRSA are independent of RPKI.  We've suggested to ARIN that they at least
consider that.  
              Although, I will say that I don't believe that is a complete
solution.  First, the problem is vanishing as more and more legacy holders
look to sell some addresses.  They do sign the LRSA.  
              But the other real market to me is all resource holders signed
an RSA to get their IPv6 addresses.  We do not see broad-scale RPKI
deployment in IPv6 either. 
              And so what strikes me is that even if you solve this problem,
it ultimately would not be a complete solution to the RPKI deployment
problems.  
              So potential next steps.  ARIN should consider RPA changes
that we've discussed here about the liability provisions under the
prohibited conduct clause.  This community needs to start a discussion about
its interest in supporting a new nonprofit to hold the certificate
libraries.  
              There is a lot of education both on the network operator side
and the RIR side about best practices and how to deploy this properly.  But
in fact this is a -- and the last thing is I think this is a change that's
coming, increasingly significant partners are getting involved.  
              I think that it's been around for a few years, but it's time
for this community to start engaging with the reality that many of the major
partners you deal with are going to start filtering and using, expecting
their partners to be deploying RPKI.  
              Thank you.  
              John Curran:  So at this time I'm going to ask Chris, you can
stand or sit, whatever you want.  I'm going to give ARIN's presentation, and
because it might answer some of the other questions and save us time, and
then we'll take questions jointly at the end.
              RPKI service risk analysis.  This is an ongoing document.  As
we learn more, we update it, but I want to give a high-level overview.  
              I have to talk about what's the risk we're managing, because
to some extent, when we talk about the legal terminologies, it's all about
making sure the right thing happens when the wrong thing happens.  
              And so we have to talk about what's the worst case.  What
could happen if ARIN services are unavailable?  How do we protect the
organization from being held by -- inappropriately being held for damages
that aren't necessarily our cause?  
              And so I'm going to talk about that, including the potential
for inadvertent service providers creating dependency on our service.  And
I'm going to talk about the ongoing analysis framework we're using for
looking at the risks.  
              This is based on the Board direction to me after looking at
the UPENN report, and talking about what we need to explore -- legal,
contractual operations, operational options -- to try to figure out can we
evolve to something that addresses some of these concerns without creating
undo exposure. 
              And I'll talk about where we could potentially come out at the
end.  
              So, I think Chris covered a lot of this.  I'm not going to go
through it in detail.  But RPKI allows a second -- it's a second service, an
optional service that allows resource holders to declare which networks can
actually announce routes for them.  
              And this is done through ROAs published by those who are
address holders.  And the act of listening to those ROAs is route
validation, ROV.  
              And the fact is that, the way it's set up, when you're doing
route validation, if you lose access to this information, it shouldn't be a
problem.  You should fall back to the routing that you're doing today
without route validation.  That's the theory.  
              And that's actually specified in the IETF operational
guidelines for RPKI.  RPKI protects customers with published ROAs from
having people inject routes that don't match the listed information.  
              And it doesn't provide any -- it shouldn't provide any impact.
 If that service is unavailable, well, then you're not protected from route
hijacking, but the loss of the service shouldn't impact your network; you
should be exactly where you are today.  
              We call the people who rely on our information to do route
validation relying parties, terminology in PKI.  And we actually provide the
information in our repository encrypted, as everyone else does.  You access
it via an encryption key called a TAL, a Trust Anchor Locator.  
              And we found an interesting problem, which is what Chris was
talking about earlier.  In order to make sure we had an agreement with the
people using this data, we have to be able to show that they're aware that
there are terms and conditions.  
              We originally started out with something very onerous; you
typed in your email and you clicked "I accept the terms," and we mail you a
link and then you take that link and click on it.  
              We evolved over time to the acceptance on a webpage where you
click on it and you download the TAL that lets you get access to this
information.  
              Now we just say download the TAL.  After a lot of analysis
legally, we've gone through three iterations, and we're at the point now
where all you need to do is, when you're installing your software, go out,
take ARIN's TAL -- all the packages direct you to the page; it says here's
ARIN's Trust Anchor Locator, which will give you access to its repository --
download it.  
              And we say on the page, prominently in the line of sight:  If
you download this, you're agreeing to our Relying Party Agreement.  
              That's unique to ARIN.  The other four RIRs actually provide
you access to their repository without you consciously doing anything, as
was highlighted in the earlier presentation.  
              US law is pretty clear.  You don't get bound to agreements
that you don't have some way of knowing that you're entering into.  So we
have to do it differently if indeed we want an agreement.  
              And that turns out to be an issue.  Some people object because
it's an extra step.  Literally you can't take the software and say launch,
build, done.  I actually have to go get this document and do that conscious
acceptance.  
              Reality is that the act of actually safely paying attention to
this information and inserting it into your route determination in your
network is a technical task and it's not trivial.  It's going to take people
work.  It's going to take people hours of planning and work to do correctly
if they don't want to get shot in the foot.  
              And so to that extent, even if it's only an hour, the act of
getting one file is not a technical hurdle.  It is a hurdle to automation
because, again, inherently automated software installation is incompatible
with your knowing acceptance unless you're aware that running the whole
package makes you bound to terms and conditions.  
              So, we have a pretty hard conflict here.  If we want to have
an agreement, then we pretty much have to have a way for someone to
consciously get the TAL.  And that's a pretty hard situation.  
              Note that the reason we need an agreement -- the reason when
we rolled out our services, we said, yes, we'll have a Relying Party
Agreement, not to say that we're unique in that.  Other RIRs put terms and
conditions on the relying parties; you just don't see them.  
              You've already agreed to them because you're using their RPKI
data; they're just not in the United States.  So they put it on their
website and you're in theory bound to it, depending on that law and
jurisdiction.  
              So, for example, RIPE has terms and conditions that limit the
damages you can claim against RIPE.  That's what we were worried about with
ARIN, but again the different legal regime says we need a more clear
contract acceptance.  
              The concern we have is that RPKI is complicated.  And we
already have people out there using RPKI to announce ROAs for their network.
 They're announcing information about which ASes are acceptable based on
their network prefixes.  And we already have misconfiguration. 
              You can go out there and look and see a number of
announcements which are invalid based on -- because RPKI has some
interesting length issues with match.  RPKI has some other issues in terms
of complexity of setup.  
              So we have people using this information on the publishing
side who are already making configuration problems.  We don't know if
someone on the relying side is going to fail open, as was discussed.  
              If our service goes unavailable, we honestly don't know if
every network will fall back to pre-RPKI routing.  That's what they should
do.  But even if a small percentage of them don't, we'll be in a world of
hurt.  
              So let's talk about the world where we're successful with
RPKI, okay.  If we're in a situation where we have global RPKI adoption, 30-
to 50,000 networks are looking at our information and validating routes.  
              Based on the error rate of configuration we see on the
publication side, based on the error rate we see on other issues, like when
they did the DNS key rollover, the first time they went and looked at who
didn't have the new key, numbers like 2 percent are quite reasonable.  2
percent of 50,000 providers is a big number.  
              We could have hundreds of service providers who fail to do
appropriate validation when we fail.  Now, again, IETF says best practice
you should -- if you can't validate the RPKI information, you can't get to
the repository, you should go to not found, and that shouldn't be a problem.
 
              But, again, even if 2 percent of people misconfigure that and
drop those routes, that means that you could have a hundred, 500 providers
who lose North America because ARIN's RPKI CA is off the air.  
              Now, there is some issues, which is that if our RPA CA goes
off the air, it doesn't happen immediately.  People have cached this. 
There's timers that apply.  They'll go back and refresh.  It's only when
they go back and they're getting to the expiration that they really have to
be able to reach us.  
              Even if we're off the air for whatever reason and even though
service providers should fall back appropriately, it's not a knife edge. 
It's not like the 200 or 300 misconfiguring providers, when RPKI is fully
deployed, they're the ones that are suddenly going to disappear.  They're
going to disappear a few every hour for the next few days until we get our
service back online.  
              Now, you'd say, good answer, John.  Don't get your RPKI
service offline.  Just have one that runs reliably. 
              We all try to do that.  But so far RIPE's had an outage; we've
had an outage.  And I can say this week AFRINIC's had an outage.  So you
have to expect the fact that this is going to happen.  
              But what we don't want to do is we don't want to add a service
to ARIN that makes the Internet more secure but actually creates fragility
for ARIN and the organization and endangers the registry as a whole. 
              That shouldn't happen, but we're not in other legal regimes. 
We're in the United States.  There's a bit of litigation in the United
States.  People like to sue.  
              And so the issues we face are somewhat different because if we
have an outage and there's several hundred providers, because RPKI is being
paid attention by 40,000 providers, and there's a couple of hundred that
can't get to North America, yes, we will face the question of why we went
down and what is the consequences of that. 
              Now, again, every one of these parties, every one of them has
made a mistake.  They shouldn't have a dependency on RPKI data.  They should
not.  They absolutely should not. 
              They have what we call unclean hands.  They don't have the
right to complain about our service being down because it shouldn't matter
to them.  
              But I would have to talk to a jury about the technical
responsibilities of the people trying to sue and talk to them about how
their routing configuration wasn't right.  
              Now, you understand now, I've got 12 random people off the
street, which I'm now talking about route waiting to and RPKI states of
invalid and found and not found.  It's going to be a great time, okay?  
              And if I have to do that a couple hundred times, oh, I'm going
to have a great adventure.  
              So what we do is we have a contract that provides for
indemnification.  When someone comes to us and says, We're going to litigate
with you because you were down, we go, You're not because you actually
agreed to cover the expenses, the liabilities associated with your use of
our service.  
              If you suffered damages or someone else suffered damages
because of your usage, you're the one responsible.  We put the
responsibility on the people using the service, because it really is their
responsibility.  All the legal agreements do is say that.  
              Okay.  So this is what we're dealing with is that we could
have a very significant issue if we go down when RPKI is well-deployed
worldwide.  
              And despite the fact that it's not our issue, because there
shouldn't be a dependency, it could be a very significant -- again, for ARIN
financially, it could actually endanger the entire organization.  
              We do what we can with the agreements to prevent us from being
inappropriately held by someone misusing and misconfiguring this data.  
              Now, here's the issue:  We have to look carefully at how we
can mitigate this.  And our past solution works great.  Actually it's
wonderful.  We have a Relying Party Agreement which we know we can say
anyone using the data has agreed to because they couldn't have gotten our
TAL.  You're not allowed to redistribute our TAL or embed it in software. 
              Everyone who is using our data I know has agreed to the RPKI
Relying Party Agreement, and every one of them has indemnified us.  And we
sleep well at ARIN.  Okay, we sleep well at night, but as Christopher's
report says, it could be impacting RPKI deployment.  
              So, what are we doing?  We are looking at all the options from
mitigation to see:  Can we put together a tapestry of solutions that would
allow us to relax our approach.  
              The Board's directed myself and our general counsel, Steve
Ryan, to do this.  We started this process.  The report came out at the end
of last year.  We started this process after meeting with the Board in
January.  
              There's going to be an ongoing thing.  It's going to take --
took a year to put the report together.  It's probably going to take us a
similar amount of time to run down all these ends.  
              We have made some incremental improvements on the way.  I want
to talk about some of the risk strategies we're looking at.  
              So one of them is that all of our ARIN customers actually
don't need, per se, a separate RPA, a separate acceptance, because they are
bound to the RPA because it's the service agreement terms and conditions.  
              When you say you use an ARIN service, if you already have an
RSA with us, then by reference the terms of that service you've agreed to,
including indemnification.  
              So everybody in North America who is our customer with an RSA,
the 6,000 members and another 15,000 end users who have an RSA or LRSA,
they're already bound by this agreement, even if they don't take an explicit
step.  
              And that actually means the parties who might be misusing the
data and wanting to litigate, we don't have to worry about that center spot.
 
              And that removes some -- some -- of the parties that we might
have to look at if we're going to relax our measures.  Luckily, what we do
for relaxing our measures doesn't actually change our status with respect to
the big part of North America.  
              And that's good because many of the people who want to
litigate us are people in North America and may have address space.  So even
if we change the RPA or change how we do the agreement, these folks already
have an agreement indemnifying ARIN for the services we provide.  
              It's possible we can rely on the RSA and its terms, and that
gives us some leeway because, if you think about it as a donut, the North
American hole in the middle has been carved out. 
              If you're an address holder, you're probably not someone who
can successfully litigate because of the RSA that you already have.  
              So that we need to consider further.  That allows us a little
wiggle room, but it doesn't handle multinational companies that have address
space elsewhere.  It doesn't handle large organizations internationally that
don't have Number Resources from ARIN.  It's not a silver bullet, but it
does reduce the number of parties that we have to think about.  
              Relying parties, as we said, the situation we face presently
is that the risk mitigations require that we look and try to have a balance
in the Relying Party Agreement.  
              Right now we have a very complete Relying Party Agreement that
includes limitations of damages and disclaimers and indemnification.  
              It may be that's overly robust.  There are some folks who have
looked and said, I can live with this except I don't like indemnification.  
              It's interesting, some of those people have signed an RSA that
contains indemnification.  So I have to scratch my head and go, well, you
already did that, but that's okay.  Let's take it on good faith.  Some
people have a problem with an indemnification clause who may be able to move
forward if we took that out of the RPA.  
              So some of the things we're looking at.  We're almost
certainly going to strengthen and make sure our existing RSA terms handle
the ARIN region relying parties resources.  
              It's possible we can look at something like insurance.  It is
possible to get insurance, particularly in a case where you go and explain
this is insurance to handle the case of the litigation expenses.  
              Now, there's two problems with this, and I just want to be
very blunt.  We actually have insurance now that covers some of this.  And
when you try to get insurance, you have to explain in detail the scenario
you're insuring against, the same relying party and route filtering and
someone misusing the data, which means you have to find an insurance agent
who -- an underwriter who is actually capable of understanding this. 
              I actually have better luck with the 12 jurors, by the way,
because random people off the street might be better than those insurance
people.  Really sorry about that.  Sorry if you're in that field.  
              We have actually done a lot of insurance work.  We actually
have reviewed our policies -- a few years ago we did an extensive review. 
We actually know how to use our policies.  We've made claims and realize
that even when insurers say, Okay, you are covered, they say, You are
covered to...we think, right now, from what we can tell, but here's three
pages of why you might not be covered if we learn more later.  
              So insurance isn't a silver bullet because even when they say,
Yes, we'll cover you, it's, We'll cover you with these exceptions.  So we'll
look at that.  May not go a lot of places.  
              Operational failure testing.  The best way to make sure no one
has a dependency that's inappropriately configured, improperly configured on
the ARIN repository, is to take the repository down every now and then.  
              And the people who are impacted will go, What did you do? 
We're like, We took it down so you shouldn't have an impact.  If you had an
impact, you did something wrong.  
              We can minimize the risk associated with our repository being
down by proactively taking it down and letting people correct the problems. 
And this actually makes RPKI more reliable because it means when it's up,
everyone's appropriately configured.  You don't have people who have these
misconfigurations.  
              Downside.  You announce a date where you're going to take down
RPKI repository, you might as well send it to certain hacker mailing lists
and say, Hey, we're leaving the Internet unprotected for these four hours
Sunday.  Do your route hijacks in this window. 
              So you may not be able to take it down in a way that you
announce in advance.  And if you don't do it in advance, how do you do
justice to your customers, because you're like, Oh, we want to take it down,
but I can't give you a warning because if I do, I'm warning the bad guys
that you're exposed.  Some fuzziness we may have to work out on that.  
              And then of course the other suggestions, separate RPKI
services affiliate.  
              I'm not going to go through these in more detail because we'd
be here all day.  But, as I said, we're going to rely on the RSA for ARIN
region parties, make sure legally that's all ticked and tied.  We'll look at
the insurance issue, but it's complicated. 
              We're going to look at operational failure testing.  We're
going to look at timers.  We have timers in our repository and we have
timers in our underlying PKI infrastructure.  We need to look at those, see
what they are and what makes sense. 
              So possible outcomes.  Let's talk about some of them.  One of
the other outcomes we're being asked to look at is reduced indemnification
clause.  We'll look at that.  
              Indemnification allows you to, very early, the possibility of
saying the party trying to litigate ARIN and hurt ARIN for its harm isn't an
appropriate party.  They don't have standing because they have indemnified
us. 
              And you can do that before early in this legal process, if I
understand it correctly.  So the good news there is that that allows you to
preemptively do something. 
              Without that, you could end up going through a lengthy trial,
even -- as I said, even if it's not our fault, it's their fault -- just to
get to the end to be able to show that your contract and your damage and
limitations apply. 
              So we like indemnification because it provides a very clear
first opportunity to take someone who is litigating against us based on
their misuse of the data and remove it.  Giving it up definitely will cause
increased costs if we ever have to defend one of these.  
              On the other hand, it's a tradeoff.  It's the type of tradeoff
that I have to look at, counsel has to look at.  We have to come to a
recommendation, give it to the Board.  And the Board ultimately has to make
a call, what's best for you because you elected them for that. 
              It's one of those heavy Board decision matters where -- the
weighty work of the Board is making decisions like this.  
              A revised RPA.  We'll look at some other aspects of the RPA. 
As I said, looking at disclaimer and limitation in liability.  If we have an
RPA, we really need to have some sort of protection.  
              So we might be able to look at indemnification.  I don't know
if that's going to work out.  But we would still end up with some
disclaimers and limitations in there because we have to.  We don't want to
endanger the organization.  
              We've been told to provide access without any RPA.  I'm not
sure this is responsible.  It increases our legal risk materially.  We are
going to look at it.  We're going to actually formally advise the Board, is
what it comes out to.  
              But for people who say we're going to get rid of an RPA, or
we're going to have an RPA that you don't have to accept -- which is the
same thing, effectively, very hard for us to prove an RPA you never saw as
binding -- it's almost the same thing if we have an RPA that you don't
accept.  
              So from that regard, if we don't have you consciously accept
it or we have none at all, we're in a big opening.  And I'm not sure we can
do anything.  We might be able to look at the language in it.  
              It's possible, looking at the full balance -- insurance,
relying on the RSA for the people in this region -- we might be able to look
at this, but it's going to be a very difficult call in terms of risk
management.  
              So that's where we are, looking at the full suite and the
response.  Chris is here.  You can stand there.  Questions?  We've got to
allow a couple minutes for questions.  We're out of time, but this is a very
important topic.  So let's get it out now.  
              Front and center.  
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC, and
most importantly not a lawyer.  I can download CentOS, Debian, any number of
free operating systems and install them. 
              Somewhere in that distribution there is a copy of the GPL.  On
the download page, there might be a link to the GPL.  At no point am I
required to read and acknowledge the GPL or whatever licenses.  
              I can think of a number of other examples.  I can download web
browsers and run them without having to click through a license agreement.  
              ISC BIND has a list of route server IPs that I'm not
acknowledged to disclaim any liability if one of those gets changed to the
address of a malware server.  
              I'm really curious what is unique about the TAL that other
examples of these types of freely available software information -- 
              John Curran:  Let's break this down because it's pretty
simple.  You're talking about software usage, GPL.  You get software, you
use it.  Software licenses are well recognized.  
              Our repository is not software.  Our repository is an
information service.  
              So from that respect, when you go and get those software
packages and install them, you're using the software under the license terms
and that's well accepted.  
              If you're using services like a DNS route zone or you're using
a certificate for SSL certificate, if you're using those services, it's up
to those organizations to decide what terms they offer their services to
you -- as-is, with no agreement, with an agreement.  
              So you have to ask them why that's a reasonable risk strategy.
 It's not that we're unique.  It's that we're actually thorough and we're
looking at managing ARIN's risk.  I don't know -- you'd have to ask ICANN
what they have as risk management.  
              Some of these organizations are unique and colorful and may
have interesting strategies for how they manage the risk.  But it's really a
question not of what's different in this regard; it's go ask them why that's
not necessary.  
              Chris Woodfield:  Right, and that's exactly my suggestion. 
This appears to be a problem that other organizations have dealt with some
way or another.  Is it possible to accept those lessons?  
              I'm talking about software, but a lot of these software have
services behind them.  I download Google Chrome, I'm going to be hitting a
CRL list.  Is there no liability if Google puts a -- 
              John Curran:  The high-level answer to your question is for
the unique case, like the DNS root zone, it's a historical artifact.  And
there are actually contracts that involve parties that -- like the US
government involved in publication -- that they may have a solution, but
it's a solution that would not necessarily be reproducible.  It may be, by
the way, when we talk about a separate entity, that might be a way to
reproduce solutions there. 
              In the case of things like SSL certs, the question is you've
got a lot of SSL cert providers, if one goes down, it's not the end of the
Internet.  
              Loss of an RIR for an entire area, North America is a very
large coverage area.  So whether or not a particular SSL provider goes out
of business -- and we've had that happen -- is up to each SSL provider's
decision.  
              But for the unique one, like the root zone, it's not that --
it's not that we haven't talked to them, it's that you have to recognize
it's so unique we'd have to reproduce it probably by the separate affiliate
option.  
              Chris, do you want to comment?  
              Chris Yoo:  To give you the lawyer's answer, software is
different.  It's protected by copyright.  Copyright creates rights that are
good against the world even if no one signs anything.  
              Why don't we ask ICANN how they do it?  We did.  And it's in
the report.  Both me and David Wishnick, who is here at the front, are happy
to talk about the details of that.  But our general take is their solution
probably doesn't provide a solution path for ARIN.  
              John Curran:  Next microphone.  Go ahead.  
              Joe Provo:  Also not a lawyer, Joe Provo, Google, ARIN AC,
legacy resource holder, random cantankerous hijack hunter, just speaking for
myself.  
              I just wish to urge continued pursuit of angles to allow us to
drop the RPA.  I don't think a new Org would necessarily be the right thing,
because the T in TAL is for "Trust," and I'm not sure how we reestablish
that in a brand-new stood-up thing, in addition to all the other issues you
identified.  
              With my service provider hat on, I like RPKI for provisioning,
not even just the ongoing route validation, but preventing the LOA-based
hijack is a good thing.  
              And in the BYOP cloud universe, we're going to see it come
back in force.  We're already seeing policies in this sphere being proposed
to bleed resources away because of the lack of TAL adoption.  
              I understand ARIN wishes to continue to exist and to service
its customers, but if all the customers go away, what happens?  
              And I understand we have really good lawyers.  So hopefully we
won't ever actually go to trial, but we'd actually prevent that situation. 
              John Curran:  Understood.  Thank you.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I'm also not
a lawyer.  I want to bring up multiple points. 
              You actually may have the inverse situations by making access
to the TAL difficult.  ARIN may actually become liable for creating security
issues, because by having part of the RIR infrastructure not there, you're
knowingly creating a situation where security is being weakened for BGP, and
that in itself could be cause for liability.  So in an attempt to protect
yourself from liability, you may actually be creating liability.  
              Furthermore, I see the TAL much similar to the way root stores
operate where Firefox, Microsoft and other browser vendors collect root
certificates and distribute them. 
              And they in themselves are not liable for how the SSL
certificates ship, are signed from those various root stores.  I mean,
essentially you could see the five RIRs as a root certificate and then boil
down from there.  
              While the situation is different with the chain of trust, I
would say that the TAL itself is essentially a public key, and I'm not
completely convinced that there is a liability issue here. 
              Now, lawyers may say otherwise, but the final issue is that if
we're going to live in a world where the RPKI servers are not 100 percent
reliable and soft failure has to be the default, we're not doing any better
than SSL where relocation is a wonderful word we talk about and doesn't
actually work in practice because the soft failure mechanism.  
              So are we essentially building a lame duck here; that if we
cannot trust that RPKI is going to work and we're going to soft fail if
validation fails, are we actually buying security, or are we buying a
feel-good thing?  That's where I want to boil it down to. 
              John Curran:  That last one is probably a question for the
IETF since they're the ones that give it as their best practices for
deployment.  It's their document that recommends that.  
              Center front.  Go ahead.  
              Steve Feldman:  Steve Feldman, CBS Interactive.  Not a lawyer,
but I do have to talk to lawyers whenever I want to buy anything that has a
contract associated with it.  And that in itself is a process.  
              So even though, as you pointed out, we already signed the RSA
years ago, it took 10, 11 months to convince our lawyers to sign it again
when we had to update it for some reason a while back.  
              We can in fact get an indemnification clause signed if we can
convince them that it's worth it.  But that's hard to do.  We have to do
that all again if we want to sign the RPA as it is.  
              For me, in my particular role, it doesn't make a whole lot of
sense to go through that work.  It would be easy if it could be covered as
part of the RSA, could be easy if there were another way to accomplish it. 
But as it is, it's not worth the effort for me.  I'm not going to adopt it
at this point. 
              John Curran:  Understood.  Okay.  
              I'm going to close the queue, keep going.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. On the light side,
I did stay in a Holiday Express last night. 
              (Laughter.) 
              On the serious side, ARIN isn't the dominant RPKI player in
the regions.  As such, we're not in a position to make much dictation when
it comes to things if we want to see successful deployment of RPKI.  
              There's a lot of personalities at play here.  A wrap-around
click-through should not be a issue.  But because we are the nondominant
player in this region, in some respects this is personality as to why this
is not being used.  
              There was just a post to the Mailing List.  Two RPKI players
that turned up in another region specifically excluded ARIN.  Not because
they consciously wanted to, because they're making a point.  That's what's
going on right now.  And it is devolving.  
              The most important thing, John, as far as I'm concerned, is
this needs to be expedient.  And another year is not expedient.  So that's
the one thing I did take from a lot of this stuff.  
              And I am not trying to get into the specifics of it because it
is way beyond my pay grade.  But it took a year to do your original report. 
And you said it's going to take probably another year to get somewhere.  
              And this is going to devolve.  Between the NANOG in October
and now, this has already devolved significantly.  And another six months or
12 months it's going to continue to devolve.  
              All I can suggest to yourself and the Board is expedience,
expedience, expedience.  
              John Curran:  I want to respond, to be clear.  We're moving
really quickly.  We really are.  But recognize that the Board has to make
this call.  This is truly that level decision, and they're entitled to have
good analysis.  
              Some of these options, we literally -- like I said, we just
got these reports a few months ago.  Some of these options, like separate
affiliate, insurance, require detailed work in order to be able to give the
Board the answer or the choices and the risks involved in each. 
              You don't want to make a half decision while one of those is
pending, because one of those options could significantly influence the
balance of the scales on how you go. 
              So I don't know how long it's going to take.  We're
aggressively doing it.  But I do not recommend the Board making decisions
with incomplete information.  And so it's just a question of us doing the
work as expeditiously as possible.  
              I want to bring up one more point just to be clear.  So we're
actually -- we have more parties doing route announcements now, more
networks doing it.  We are still growing.  Not just in terms of percentage,
but in terms of count, in terms of objects, and networks covered, we're
actually moving up slowly but surely.  We are now No. 3.  Used to be No. 5. 
It's not a percentage issue, but then we're also a very large area. 
              When you say we're not the dominant player, we see a lot of
RPKI activity going on in America, and this -- Canada, US and the Caribbean,
we see a huge amount of activity.  
              The slope doesn't necessarily match other places, but that
doesn't mean it's not growing even right now.  
              Kevin Blumberg:  No, the issue is that other regions are using
what's going on and turning off ARIN, or not turning it on in the first
place, which is not going on elsewhere.  
              And we are not, by numbers, the No. 1, right?  
              John Curran:  Sure. 
              Kevin Blumberg:  I'm not asking you to do a poor job.  I'm
saying throw whatever you can at this because it's going to get worse fast. 
Thank you.  
              John Curran:  I actually closed the queues earlier.  So
everyone after the remote monitor, I'm not sure what you're doing here. 
We're well beyond time.  
              I said everyone after the remote monitor.  
              Go ahead, Owen.  
              Owen DeLong:  Owen DeLong, ARIN AC.  You talked about
announcing an outage ahead of time being a recipe for the hackers.  
              Couldn't you have an authenticated list of people that want to
be notified that have somehow authenticated themselves as being relying
parties and announce only to that list?  
              John Curran:  Could. 
              Owen DeLong:  Thus mostly avoiding notifying the hackers?  
              John Curran:  There are options, and we need to tease these
out.  That's a great idea.  
              Go ahead, Andrew.  
              Andrew Dul:  Remote comment from Jason Schiller, Google, ASO
AC:  Thank you for this presentation and your continued work to reduce the
gap and barriers to usage of RPKI in the ARIN region as compared to the
other four.  
              Please continue this work and increase my fees if that's
what's needed to make appropriate progress.  Can we please get this
presentation and updates of this progress at the next NANOG meeting?  
              John Curran:  Next NANOG meeting, understood.  If the program
committee honors me, sure.  Yes.  
              Joe Provo:  My apologies, because even writing down, I forgot
something.  Joe Provo, Google, ARIN AC, speaking for myself.  
              In addition to fees, since there were concerns about
insurance -- and my apologies if it was in the report -- have we explored --
has the Board explored discussions with the other RIRs for increasing the
Joint Stability Fund to cover this sort of eventuality?  
              John Curran:  A Joint Stability Fund is a very small number
compared to our organization.  If we see a damage that's order of magnitude
a year or two worth of our fees, order of magnitude our reserves, there's
insufficient water and there will never be enough to sustain us.  
              So unfortunately we would take down the Joint Stability Fund
and the other RIRs in the process.  That's really the issue we face, is that
the problem is that in a litigation like this, if you face that from several
hundred parties, you actually -- the uncertainty of the outcome combined
with the length and the process to get clear encourages settlement.  And
even that could be debilitating to our organization.  
              So I guess the work that we're most likely to end up, if we do
anything with the other RIRs on this jointly, would be look at, for example,
maybe there's joint publication possibilities.  
              And that's not unheard of.  I'm not sure we'd incur the risk
and then share the risk with our RIR brethren.  Seems to be rather cruel in
a number of ways.  
              So microphones are closed.  Anything from remote?  Chris, only
one question for you, if you want to say something in closing.  
              Chris Yoo:  Only that I'll be around lunch, if there's other
engagement you'd like to do.  We'd be open to it because this is a process
and a dialogue.  
              And thank you for allowing us to inform and engage the
community.  
              (Applause.) 
              John Curran:  At this point we have a couple of presentations
before break, but I am not cruel.  So we are going to take the scheduled
break at this time.  
              And so, folks, go outside, and we're resuming here promptly at
11:00.  
              So take your break and I'll see you back here at 11:00 a.m. 
              (Break from 10:32 AM to 11:00 AM.)
              John Curran:  Welcome back.  If everyone would get seated,
we'll get started.  We ran a little late because of the active conversation.
 
              We're going to take the presentations that did not get done
before the break and we're going to resume with them.  We'll have the ASO AC
Update and IANA Review Committee Update.  
              Come on up, Kevin Blumberg. 
ASO AC UPDATE
              Kevin Blumberg:  Good morning.  I'm Kevin Blumberg, the vice
chair of the ASO AC.  I promised John I'd run through it quickly because we
lost a lot of time.  And the clicker is not clicking.  
              So you're going to hear two terms quite consistently:  NRO NC,
which is the Number Council, and AC.  
              For laymen, they're the same thing.  We sit on the NRO NC when
we're at RIR meetings.  When we're at ICANN, we're called the ASO AC from an
ICANN perspective, but it is all the same people.  They're interchangeable,
by and large, without getting into any complexity. 
              The ASO AC is made up of 15 people -- two are elected by the
community, one is appointed, times five regions.  So we're a body of 15
people, two elected and one appointed.  I'm actually the appointed person
from the ARIN region.  
              We have a number of observers.  We have ICANN staff, we have
the ICANN Board members, and we have RIR staff that join us regularly.  
              The terms of office in the ARIN region are for three years. 
But they do vary quite significantly between the regions.  
              What we do:  Every once in a while, when it comes to number
policy, the ICANN Board will ask us questions.  And we're there for the
ICANN board to be able to provide them with feedback based on information we
received from the communities, et cetera.  
              We select two ICANN board members, and we'll talk about that a
little bit later.  And we do appoint some people as part of our
responsibilities under the various agreements that we have between ICANN and
the RIRs.  
              We do select a number of things, like the NomCom within ICANN.
 We have a monthly call.  We have a yearly physical meeting.  That just was
a couple weeks ago.  
              Each year we elect a chair and two vice chairs.  And the
important thing is that the chair and the vice chairs cannot be from the
same regions.  So we're very diligent about making sure that there is
regional representation among the RIRs in all of the things that we do.  
              And we have a list of all the members for the different
regions.  For ARIN, I'll mention it's Jason Schiller, Kevin Blumberg and
Louie Lee that are the members for that region, for our region.  
              We also provide participation records.  So for 2019 we've had
four meetings.  And as you can see, we keep track.  It's on our website. 
The link is there.  And we feel that this is very important for transparency
so that people, especially when it comes down to elections, know what the
participation is when it comes to their representatives on the ASO AC.  
              The ICANN 10 Board seat election just concluded.  We had three
candidates.  One of them withdrew on February 18th.  I'll leave that up
there.  Just move to the next. 
              And on March 27th we announced that Maemura Akinori was
selected for Seat 10 to serve for another term, as he's the current Seat 10
selection.  
              We've nominated Brajesh Jain to the NomCom.  And just recently
I was asked to sit on the Multistakeholder Ethos Awards, which is a small,
little ICANN project that awards to somebody who deals with all of the
different stakeholder groups within ICANN in a positive way.  It's a
three-month sort of thing. 
              And lastly, I wanted to talk about the ASO review which
happened in 2017.  On the NRO's website, there's a full list of all 18
recommendations and the current status of those recommendations.  Many of
them have been completed.  
              The ASO AC is nearing completion on all of the tasks that it
was given by both the NRO EC and the direct requests out of the
recommendations.  
              And the two things for this community that are important: 
One, our Mailing List will become an open archive.  So historically the
Mailing List has been closed, and really only the announcements list that
got used once in a while for global policy would call.  But our day-to-day
sort of work that goes on will be open, and that's happening in the next 30
or so days.  
              And the same with audio conference calls.  We're going to be
switching platforms to allow any community member who wants to join in to
the audio conference calls to be able to join in, to make it less of a black
box in terms of what the ASO AC does.  
              We've got a website.  One of the recommendations was to redo
the website.  That is coming this year.  But in the meantime everything that
we do is on the website at aso.icann.org.  
              If there are any questions?  And I'll be around for the rest
of the conference if you do have any questions about the ASO.  
              Thank you.  
              (Applause.) 
              John Curran:  Next up, Louie Lee to give the IANA Committee
Update. 
IANA REVIEW COMMITTEE UPDATE 
              Louie Lee:  I'm Louie Lee.  This is Louie's hat.  New hat. 
Whoo.  All right.  If you want to go back to your email, go ahead. 
90 seconds.  Go.  
              This stuff is boring because the IANA operator, as long as
IANA operator is doing what they need to be doing for us, there's really
nothing to get riled up about.  
              Talk about the formation, the role of the Review Committee,
the members, current work status and the transactions that have happened
since last update.  
              A little about the 2018 report.  It's been published.  Nothing
big going on there.  And then a little bit about the community engagement
and input.  That's the one you should look up from your emails.  
              Now, the Review Committee was chartered by the NRO EC, formed
a few years ago.  This was based on the CRISP recommendations that we have a
community group to make sure that the contracted services from IANA to the
RIRs are happening and the work is good and they're staying with the SLA. 
              The role is spelled out online and shown to you.  We had also
put this in the preamble of our operating procedures, and the new operating
procedures should be posted soon.  The link to the current site is below.  
              Now, who are we?  We are 15 members from three from each of
the RIRs.  Now, in the ARIN region, the two elected members are the same
that were elected as the NRO Number Council.  
              So just a slight change from what you heard from Kevin in that
the elected members from the ARIN region for the NRO Number Council also act
as Review Committee members. 
              We have some changes.  The ones highlighted in bold are the
new members for this year.  
              So you see Richard Jimmerson listed.  He took over the seat
for Nate Davis who retired last year.  
              Current work status.  We are still refining our operating
procedures and continually seeing what we need to update for the changing
environment.  We have not all that many changes, but we see some gaps in
places like -- for instance, we added a process for expedited performance
report just so that we can produce a report for out of cycle, in case
something happens there where it needs to be done.  
              We clarified the RC member and community engagement piece to
scope it down to just things that are related to IANA services performance
to increase communication with the community.  
              So by the end of this year, we'll begin to prepare for the
report for this 2019.  
              Since our last update, there has been one reported transaction
on the IANA website.  This is related to an ASN request, and that has been
met with 100 percent reliability, and everything good.  
              Now, there was one more piece of activity that happened but
it's not yet recorded on the website.  This is related to the /22 v6 that
was assigned to RIPE back in March.  
              The 2018 report, yes, has been published, back in March 5th. 
If you want to read the report and read the full conclusion, the link is
right there in my presentation.  
              Now, the conclusion really is just that there were two v4
allocations, three ASN requests.  There were no indications of failure or
near failure by IANA under the SLA.  No concerns from the communities.  And
we perceive there had been sufficient community outreach and involvement.  
              We did receive zero comments during our open comment period. 
However, two came in after the report was published.  They were related to
formatting and accessibility.  So we will include those comments as
improvements in our seeking to improve the report for next year.  
              So here is where you look up from your email.  The community
engagement part.  We want to make sure that we are still doing what you need
us to do.  If you read the report and you find that there are questions you
have about what activities have been going on, please reach out to us. 
              We do have the open comment period for when the annual report
comes out, and we're coming to these meetings.  We're online.  Please do
reach out to us for that.  
              With that, are there any feedback, observations or questions? 

              (Applause.) 
              Thank you very much. 
              John Curran:  We're now going to have Kevon Swift come up and
give the global report, LACNIC.
GLOBAL REPORT: LACNIC 
              Kevon Swift:  Thank you very much, John.  Good morning,
everyone.  I'm very cognizant of our time so I'll try to be a bit quick, a
bit swift.  I have a lot of information on these slides.  But, please, if I
gloss over something, feel free to approach me at any time.  If you would
like more information, I'll be happy to help you out and point you towards
further details on what I'm about to present. 
              So today's presentation is going to focus on three topics. 
We're going to talk about excellence in Internet Number Resource management,
covering some of the results from our Customer Satisfaction Survey, we're
going to talk about our resource administration platform, Mi LACNIC.  
              Also going to touch about our continued strengthening of a
secure, stable and open, continuously growing Internet -- what we're doing
in terms of security, stability and resilience, IPv6 deployment and our
training activities.  
              And last but not least, I'm going to talk about some of the
community things we're doing to promote that inclusive bottom-up Internet
governance model.  
              Moving right along.  So what we saw here in 2018 is that we
stand at a current rate of 90 percent satisfaction from our members.  That
has been quite consistent over the years, as you'll see between 2014 and
2016.  And of that 92 percent it's actually about 68 percent are actually
very satisfied with our services.  So we do get this favorable feedback from
our membership.  
              Our membership.  We are now at 9,000 members.  And what is
interesting to note is that a lot of that growth is attributed to two main
categories that have been opened up since 2017. 
              You'll see them right there at the bottom of the list. 
They're the Nano and Micro categories.  And Nano and Micro categories are
really for those very small entities requesting anywhere around a /20 or /22
resource space.  
              So we have seen thousands of those grown over the last couple
of years.  And one of the reasons why, as you may be well aware, given the
current policy that we have for exhaustion, which is our new members policy,
or some of you may know it as our new entrants policy, existing members can
no longer get [fee for space] from us.  We only give fixed allocations of
either a /22 or /24 to new entities.  
              And as a result, you do find that a lot of huge corporate
customers are deciding not to rely on their main service provider and come
to us to become members directly.  So that accounts for all the thousands of
Micro and Nano providers at this point.  
              The current pool is about 2.3 million addresses.  That
includes about 1.3 from the free aggregate pool plus 1 million in terms of
revoked and returned addresses.  
              And initially we had anticipated that we would have enough
resources, v4 resources, to run from 2017 straight up to about 2022.  And at
that point we will have absolute exhaustion.  
              But at the current rate at which the Nano and Micro members
are growing, we foresee that we'll be completely out of v4 resources by mid
2020, by August 2020.  That's the new projection, and that's because of that
growth we're having in our membership scheme.  
              Resource transfers.  So there was the implementation of the
policy, the change to Policy 2.3.2.18, a policy that is well known.  It
deals with allowing intra-regional transfers outside of mergers and
acquisitions.  And I would say quite honestly in the LACNIC region we
haven't had as much -- we've had an insignificant amount compared to the
ARIN region. 
              One of the things that we do to support those transfers, to
support this secondary market is that we have a listing service available
for all members.  
              And this listing service you can either sign up either as a
buyer or seller or an intermediary that can serve as escrow for any of these
transactions.  
              So 33 transfers over the last two years, not a lot.  But it is
something that we have.  And, of course, we are going to see at the upcoming
LACNIC meeting more discussions about inter-regional transfers and, of
course, conformity with the three RIRs that do allow this.  
              With our board of directors, we've had re-election of one of
our directors, Ms. Alejandro Guzman, who is in the audience.  And we have
also had for the first time the election of two new directors, Esteban
Lescano from Argentina and Evandro Varonil Brazil.  
              Mi LACNIC is the resource administration platform that I
referred to earlier.  And it's really an in-house solution that we
developed.  It shows a lot of information, well, [various information] that
are relevant to our members -- IP/ASN, reverse DNS, account statements, et
cetera.  
              It also hosts the listing service and it gives information on
our training and events.  So it's really a one-stop shop that we've created
to really just facilitate that members experience that we have within the
LACNIC region.  
              Strengthening security stability and resilience.  So a lot of
outreach being done on resource certification.  As some of you may be aware,
there's a project at LACNIC called +Raíces.  And +Raíces is basically a
facilitation service to allow for the implementation of copies of DNS root
servers.  
              So in 2018 we've had five such applications for the +Raíces
program.  And the latest two, [Monterrey, Mexico], with the installation of
an I-root server, and Panama City with the K-root.  [CHK] 
              In terms of the ASNs, the visible ASNs in our region, 7,868,
we see about 40.65 percent announcing v6 traffic, which tends to be one of
the highest of the regions.  And these are the real movers and shakers in
terms of the IPv6 economies in our region. 
              We have Uruguay standing on top with 34 percent with respect
to their total Internet traffic; Brazil is closely behind; Mexico; T&T;
Ecuador; Saint Martin, the Dutch side; and then others like Peru, which has
been there for a long time but they're a bit -- their growth seems to be
flattening out a bit or remaining constant, or stagnant somewhat.  
              Argentina, Bolivia, Guatemala, between 5 and 7 percent.  And
then slightly over 1 percent, Dominican Republic and Belize. 
              And some of the interesting things about this information is
that just one or two years ago half of these countries were not on the list.
 We only had about four prominent movers and shakers, which would have been
Brazil, Peru, Argentina and Ecuador -- sorry, and Trinidad and Tobago.  
              And many times it could be attributed to the actions of a
dominant operator in the country.  In other instances, we've seen where
things such as IPv6 task forces have been really, really relevant to getting
people on board doing [censustization] [and informing] your stakeholders,
your digital entrepreneurs as to the importance of deploying v6.  
              Online training.  We have webinars.  We have reached up to
4,871 people through our webinars last year.  You can see here the variety
of subjects that we discussed, the most popular, of course, being IPv6.  
              And we also have from our online training platform 1,517
people being trained on IPv6 and 496 on BGP.  
              So our online training platform, our LACNIC campus, we offer
three types of courses -- basic IPv6, advanced IPv6, and BGP RPKI.  We've
seen a significant amount of growth, about 10 percent, compared to 2017 in
the use of the online campus. 
              And I should not be saying this, I'm sorry, [Jenina], we'll
soon be offering our IPv6 basic course in English just to make sure we reach
our entire membership and just reach out as much as possible everyone who
needs to have this information.  
              And why is it important?  Because it's a well-known fact that
LACNIC members, some of the record makers in the world for having both v4
and v6, about 92 percent, but what we realized is that despite the
availability of IPv6, many members were slow to implement it.  
              And looking at statistics, it doesn't give you a fair
assessment as to what really is happening.  So for that reason we decided to
take it at a national community approach, national technical communities,
and identify who were the decision-makers within each community responsible
for promoting v6 adoption.  
              And with that in mind, we started conducting these IPv6 for
Decision-Makers visits.  They're high-level visits involving our CEO, Oscar,
and other CEOs and other decision-makers in other countries.  
              We typically tend to target [ITT ministries], regulators, ITT
associations, IXPs, large operators.  Those are the types of stakeholders
who we reach out to.  And we try to create this very intimate space where we
can ask them and have them ask in confidence some of the questions that may
seem silly at times.  
              But it's really about creating this intimate space for them
where they can ask in confidence some of the questions they have about v6
deployment.  
              A lot of things tend to focus on training opportunities and
knowing how to operate in a v6 world, how to move away from scarcity
management.  But we have found this to be very useful.  
              So 2018 we went to four countries -- Guatemala, El Salvador,
Belize and Honduras -- and we intend to continue this type of engagement,
talking about v6 for decision-makers. 
              One of the things that is in here is that we also have from my
department, the Strategic Relations Department, a lot of requests from
public entities wanting to know what is the best way they can talk about v6
deployment within public administration.  
              Many times they're coming up with Public Policies, directives,
et cetera.  One of the biggest messages that we have for them is that you
cannot force v6 deployment among ISPs, but where there is control within
public administration, where you do have operators of public infrastructure,
we do have a couple of recommendations that they can use.  
              And thus far we have been engaged by a lot of regulators and
ministries across the region, and we do provide that sort of feedback and
input for that.  
              Routing Security Project.  Recently through the Open
Technology Fund we have a project between LACNIC and NIC Mexico, and this
project deals with RPKI validation.  As it stands, LACNIC relies on RPKI
validation from RIPE.  
              There is one exchange point in the region. That's the [NAP] of
Ecuador.  That does [route RPKI] validation but is not something that is
quite common as yet.  But we hoped to see this really take off soon.  
              [FRIDA], the Regional Fund for Digital Innovation in Latin
America and the Caribbean.  Last year our FRIDA fund had two special
categories in mind.  We were looking at closing the digital gap through
community networks, something that we've been doing in partnership with
Internet Society, and we are also looking at closing the gender divide in
technology, which relates to a host of other issues that we see across the
region and is showing that there's fair and equitable access to technology
use and creation across Latin America and the Caribbean.  
              So FRIDA is about awards, grants, [inventions] and scale-ups
for existing ideas.  What you see here are the FRIDA awardees from last
year.  For community networks, we have awardees from Argentina; community
networks established in Brazil and Colombia.  
              And in terms of the gender divide, we have Wikimedia looking
at removing bias in Wikipedia content.  So it deals with eliminating
machismo influences that you find on public information and increasing the
presence of more female editors for Wikimedia content across the region. 
              And we also have an initiative from the University of the
Republic of Uruguay for encouraging women in careers in technology and other
grants in Chilé and Colombia.  
              Ayitic Goes Global is our flash initiative initiative in
Haiti.  It is the successor to our first project in Haiti called Ayitic,
where we are trying to show off the skills of the Haitian community.  We go
in and we ask the community what are their real needs.  And we initially
trained the community in topics regarding v6 deployment, Internet security,
wireless networks, network management in general and the like.  
              So with Ayitic Goes Global, we decided that we are going to
change the direction slightly.  We're still going to work with the Haitian
technical community, but we've identified another key target audience that
can benefit from some form of intervention.  
              And this target audience deals with women and girls,
school-leaving girls from Haiti who have limited choices and options in
terms of being employed. 
              What we're doing is that we are training up to 300 young women
and girls in data processing and related topics so that eventually they'll
be able to support business operations remotely for companies founded in
Haitian diaspora.  Most of them we have identified tend to be in North
America, in France and in other regions. 
              So the goal is 300 women and girls being trained in addition
to about 150 Haitian technicians that will work on the infrastructure
issues.  
              We have encouraged the creation of a cluster, where they
identify security issues and small mini projects.  They can work on
resilience of Haitian infrastructure.  And we are hopeful -- at this point,
we do have an employment coordinator in place to have the girls secure
contracts to do the remote work.  
              LACNIC Google workshops.  So last year we conducted three
workshops focusing on IP traffic management and also on digital
entrepreneurship.  And I would say that these workshops are quite
successful.  
              They were undertaken in Trinidad and Tobago, Guatemala and the
Dominican Republic.  So, for instance, in the Trinidad and Tobago [leg],
there were up to 120 professionals that came out.  
              It's all in all, been a really successful experience that
we've had.  And we look forward to more engagements and collaborations in
the future. 
              I'm looking at the time.  I'll be really fast.  Two more
slides.  
              We've had an increase in the number of proposals at our
meeting.  So in 2018 we've had a record 14 proposals being presented. 
              And you can see what the reference is compared to the other
years on that slide.  And in terms of community building, participation, we
have huge numbers of remote participants at our meetings. 
              We have another series which is called LACNIC on the Move,
which are more in-house, community-based engagements with local Internet
communities.  
              So the LACNIC on the Move last year, there was one in
Paraguay.  There was another one that was paired up with the LACNIC Google
training in Trinidad and Tobago.  And this year we intend to go to Curaçao
to have that one-on-one interaction with the Curacaoian technical community.
 
              And last but not least, we were voted second best place to
work in Uruguay.  It's the seventh year in a row that we were voted quite
highly and favorably in terms of a great place to work. 
              And, please, come to LACNIC 31 in the Dominican Republic. 
We'd be more than happy to have all of you there.  It's, again, in the
Caribbean.  You have no excuse; you already know what you're in for -- rum,
sunlight, sunshine.  Please do come along.  Thank you very much.  
              (Applause.) 
              John Curran:  Any questions for him?  Just want to make sure. 

              (No response.)
              (Applause.) 
              Okay.  So it is now -- it's right on time.  How wonderful. 
We're going to go into our policy block for the morning.  And this is
ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers.  
              David Farmer is going to come up.  This is a Draft Policy. 
This is just an AC presentation.
ARIN-2019-4: ALLOW INTER-REGIONAL IPV6 RESOURCE TRANSFERS 
              David Farmer:  Okay, here's the problem statement.  Basically
there's an operational need for inter-RIR transfers of IPv6 and then focuses
on RPKI Trust Anchor issues that we've discussed already today.  
              The policy statement here, is here and basically it's
effectively adding IPv6 to IPv4 and ASNs in Section 8.4.  
              Some discussions so far.  Wouldn't it make more sense to
increase the deployment of RPKI in the region?  
              I would prefer to keep the v6 blocks cleanly in the RIRs,
their each RIR.  This policy seems nice.  It removes the weird and, I think,
unnecessary distinction from that commenter between the address families. 
And finally why is v6 different, essentially?  
              So there's been some additional use cases discussed, because
as it says here, the current problem statement almost exclusively focuses on
RPKI issues.  
              And there seems to be some other reasons why one might want to
transfer v6 exclusive of RPKI.  And a couple of those are stated here. 
They're basically around reorganizations on a global basis.  
              Issues with the policy statement.  Currently it's basically
changing 8.4 which was originally sort of the specified recipient's
transfers to other inter-- on an inter-RIR basis.  
              Yes, you can transfer to yourself and the other RIR by
designating yourself, but that's more of a side effect than an intended
result of the policy.  
              So as a result IPv6 resources can be transferred to other
organizations in other RIRs.  But we don't have -- because 8.3 isn't also
modified we can't do that in the region.  So this creates a disparity
between what you can do inter-regionally and within the region.  
              So there's also some significant opposition to specified
transfers, maybe a little less for transfers to yourself in a region.  But
there's even opposition to that.  
              So, transfers to the same Org.  There's, in current policy,
effectively that's what 8.2 is about, for M&As and other kinds of transfers
or reorganizations and various things. 
              Maybe a way to solve -- if we want to do IPv6 transfers to the
same organization in other RIRs, maybe the way to solve that is to change
Section 8.2 to include inter-RIR transfers to yourself instead of adding v6
to Section 8.4 which is fundamentally about specified transfers.  
              Here is some proposed alternate text just so that people have
some ideas of how this might be accomplished.  Basically the idea is add
reallocations to the title so that it makes kind of sense, and then add an
"or" clause at the end of 8.2 that basically says if the resources are being
transferred to or from an administration of another RIR in the name of the
current registrant or an organization under common control.  
              This is where it's kind of like an M&A because depending
upon -- sometimes when you are transferring -- sometimes when you're doing a
multinational, you actually have multiple legal entities in the different
countries.  They're under a common control but they're different legal
entities.  They're not the same registrant per se.  
              So IPv6 transfers in the other RIRs.  Currently AFRINIC, APNIC
and LACNIC basically only allow M&A transfers of IPv6 within their region.  
              There are policies listed here to change that.  The policies
are all in flux.  But basically a couple of them seem -- my read of APNIC's
proposal is that it's to allow sort of this M&A kind of transfer, not what
we call specified transfers.  
              And I'm having a hard time interpreting LACNIC's proposal, and
then AFRINIC's proposal seems to be going to more like a RIPE-based solution
where it's allowed for M&As and to other Orgs, both in region and out of
region.  
              So a few questions.  Should the other use cases be added to
the problem statement?  Are there additional use cases that we need to
consider and be added to?  Are there use cases for transfers to different
organizations that we need to consider in region or out of region?  Should
IPv6 transfers be limited to effectively the same organization but allowed
for inter-region, or do we want to allow specified transfers as well?  
              And do you support the proposed text or the current text?  And
does anybody have any other suggestions?  
              It's now time for you to get up here and talk.  I'll leave the
questions up so that people can -- 
              Paul Andersen:  Okay.  Good morning.  Let's get in it.  Who
would like to be the first to comment on this Draft Policy.  Microphones are
open.  
              Alison Wood:  Hello, Alison Wood, state of Oregon, ARIN AC. 
David, in your research on this policy and the reciprocal policies in the
other RIRs, is this a hot and heavy thing?  Are there a lot of IPv6 address
spaces that are wanting to be transferred, in line to be transferred?  Or is
this more of a future type policy?  
              David Farmer:  I haven't had a chance to dig too deep into
this.  We just got this a few weeks ago.  And so I really can't answer that
question too much.  
              I wanted to review the other policies because I knew those
were out there.  But I haven't had a chance to actually review comments on
any of the other policies or to see how -- I don't have a sense of where
they're going in the other regions yet, nor how much v6 transfers.  My gut
tells me that the v6 transfers are fairly negligible.  But I will work on
getting those details.  
              Alison Wood:  Okay, thank you.  And I do support this policy. 

              Paul Andersen:  Thank you very much.  Front microphone.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I'm
currently neutral on this policy.  While I can see a valid use case for
mergers and acquisitions of bringing all IPv6 under a single umbrella, I'm
somewhat wondering about the need and logistical overhead, given that most
of the IPv4 transfers, especially across regions, is to deal with the fact
that exhaustion and moving of v4 blocks -- the v4 blocks are very valued
commodity while we have lots of v6 address space.  
              So I'm looking at this and I'm trying to see if there's a real
upside versus being able to consolidate because it means that then when you
look at the blocks allocated to each RIR, you'll have IP addresses within
those blocks that then exist in a different RIR, and it sort of muddles
which IPs actually belong to which region.  And I worry of opening Pandora's
box here. 
              Paul Andersen:  I know you're neutral on the policy, but do
you have a view on the problem statement, whether it's a problem that should
be solved?  
              Michael Casadevall:  I'm currently neutral because I'm not
hearing a strong use case.  I'm not against it, but I'm not for it either. 
              David Farmer:  So, hearing you, I think I hear you saying
probably those other use cases are important if we're going to further
consider this?  
              Michael Casadevall:  If it's strongly important that v6
resources need to be transferred and those use cases are valid then I would
support the policy as written.  
              I'm hesitant that the use cases are valid.  I'm not sure that
type of consolidation really is all that important.  And you deal with the
risk of basically carving up the / -- I don't remember the size of [R1] has
and their allocation to /12 becomes very messy instead of having it in
organized blocks that we currently have it in. 
              David Farmer:  Thank you. 
              Paul Andersen:  Next speaker.  
              Owen DeLong:  Owen DeLong, ARIN AC.  I'm opposed to the policy
and I'm opposed to the problem statement.  The result of this policy, if it
were adopted, would be to enable RIR policy forum shopping and essentially
eliminate the territorial exclusivity intended in ICP-2. 
              It's not a good idea to do that for a multitude of reasons. 
The problem statement is indeed one which should be solved.  However, v6
transfers are not the way to solve it.  
              The way to solve it is to either enable the use of alternate
Trust Anchors or for ARIN to solve the Trust Anchor problem that was
discussed in the previous session.  
              It is not -- it's a valid problem statement, but the solution
does not apply to the problem statement.  The solution is a workaround with
dire, unintended consequences. 
              Paul Andersen:  Can I clarify if you think the problem
statement is valid or the problem statement is valid as it relates to the
policy process?  
              Owen DeLong:  The problem statement is valid as it relates to
the policy process.  But the policy proposed is not a valid solution to the
problem stated. 
              Paul Andersen:  Okay.  Thank you.  
              Same microphone, please.  
              Kevin Blumberg:  Kevin Blumberg, The Wire.  I'm opposed to the
policy.  And I want to split it into two sections.  
              I do not believe the -- I believe the problems are real, but I
don't believe that they are actually within the policy process, and I'll
explain why.  
              In the case of RPKI it is either a technical issue not
relevant to policy, or the solution should be a global policy that addresses
this for all regions at once and brings uniformity among that through
possibly moving to IANA as an example to handle RPKI.  
              This is not a valid thing that can be dealt with by just
shunting off from one region to another.  If our region feels that we're
dealing with it in the right way, then that is fine.  But this is not a
policy issue that can be resolved.  It needs to be done elsewhere.  
              In regards to the M&As, the entire reason for allowing the v4
and AS transfers was scarcity.  That does not exist with v6.  
              The communities, not just our community but all the
communities, spent years grappling with inter-RIR transfers to finally allow
them based on the scarcity and the immediate need for those number
resources, specifically, in other regions.  
              There is no scarcity issue with IPv6.  And the entire model
with specified transfers, specifically, had no concept of mergers and
acquisitions and the idea of forum shopping.  
              Again, if you want to do that, look to ICP-2 and look to
changing that and look to changing the whole way that we're dealing with
things.  But this is not the place for it.  Thank you.  
              Paul Andersen:  Thank you.  Microphones are still open. 
Please approach a microphone.  Or, of course, remote participants, please
type your question and it will be read into the record as it will be right
now, as an example.  
              Andrew Dul:  Speaking for Jason Schiller, Google, ASO AC.  I
think there are three real issues we need to address.  One, support M&A
[(indiscernible)] when the new legal entity is not in the ARIN service
region.  Two, support M&A where new legal, perhaps more strongly rooted in
another region entity prefers to be serviced by a different RIR.  Three,
support of M&A where ARIN region stuff is divested and the remaining bit no
longer meets Nexus requirement.  
              I also support removing barriers to RPKI.  I hope that
everyone agrees that solving that issue is urgent.  
              Paul Andersen:  Thank you for that.  Microphones are going to
close in a minute if I do continue to have a lack of people at the
microphone.  So please approach a microphone quickly.  Rear microphone. 
              Mike Burns:  Mike Burns from IPTrading.  There was a question
about the demand for IPv6 transfers, whether it's a now thing or a future
thing.  
              I took the opportunity to look at the RIPE transfer list for
IPv6.  And there have been 1355 IPv6 transfers processed at RIPE, which
leads me to infer that there's a need, absent the scarcity argument for
these transfers.  So I support the policy. 
              David Farmer:  When you looked at that, does that distinguish
M&A transfers from transfers to other organizations?  
              Mike Burns:  No, you'd have to go through and look at -- 
              David Farmer:  So that could very well be 1300 M&A transfers. 
              Mike Burns:  It's doubtful that it's all M&A transfers.  When
I glanced at it, it looked like there were several specified transfers
[(indiscernible)] not matching the Org.  But in any case, you can infer
there's a business need for these transfers.  
              Paul Andersen:  Thank you for the comment.  Microphones will
be closed at the end of this comment.  Approach microphones quickly.  
              Michael Casadevall:  Michael Casadevall, NARALO.  I want to
just append my previous comment that for reasons for RPKI this is not the
way to fix this, that I consider that use case invalid.  It slipped my mind
when I said it originally. 
              The other question I need to ask is for entities that end up
with ARIN IP blocks that don't exist in the United States because of mergers
of acquisition, is there a real need to have them transferred to other
regions?  
              I'm looking at this and I can understand wanting to only have
to deal with only one RIR, but I'm wondering if once an IP block is assigned
it should live with that RIR and stay with the same policies throughout its
entire lifetime until it's released back and a block is received from
another vendor because as mentioned by Owen, IPv4 block transfer became out
of necessity, not because it's necessarily something we wanted to do.  
              Paul Andersen:  Thank you for the comment.  The last comments
will go to the remote participants and/or Andrew if he has his own. 
              Andrew Dul:  Remote participant, Brian Jones from Virginia
Tech.  I don't have enough information to make an informed decision about
this policy.  
              I do feel like it may open up problems with understanding
where a block of IPv6 addresses are located as opposed to who supports them.
 Therefore, I am leaning toward not supporting this proposal with the
information at hand now. 
              Paul Andersen:  Thank you for that.  The microphones are now
closed.  I'll thank David for the AC presentation.  
              (Applause.) 
              Thank you.  All right.  Small change from standard process. 
The AC chair, just so you know, has the ability to ask me to ask polling
questions on any topic.  And while not normally on a Draft Policy they've
asked me to ask the question:  Does the community wish to see the AC to
continue to work on the policy statement, so specifically the policy as it
is written?  
              So I will ask for those first in favor and against, remote
participants obviously in the channel.  So seeing that my pollers are ready,
I will ask all those that are in favor of the Advisory Council continuing to
work on the policy, 2019-4, please raise your hand nice and high.  
              Thank you, lower your hands.  
              Those that are opposed to continuing to work, please raise
your hand nice and high.  And of course on the remote, please indicate.  
              Thank you, you can put your hands down, including Kevin, I
think, has his hand up.  
              Let's just wait for the result.  Didn't look like a lot of
hands.  It's that lovely social, that every time, without cause, staff
always put on an amazing social.  So, hopefully you all had a chance to get
out there yesterday on the beach.  They had to shove people out at 11
o'clock, so that's always a sign of a good social.  
              Will we be breaking early, John, or are you going to try to
squeeze one in with our 10 minutes, a presentation?  Well, if we do the
presentation earlier, it means it might end earlier.  That's all. 
              John Curran:  Well, we do have a transfer update. 
              Paul Andersen:  We have 10 minutes. 
              John Curran:  And it could be done in 10 minutes, the transfer
update, John?  About 10 minutes?  
              Paul Andersen:  Why don't we get the transfer update queued
while I get the results.  
              All right, for the show-of-hands result on the matter of
2019-4, we have 110 people in person or remote.  
              We have seven in favor and nine against.  So these numbers
will be provided to the AC for their input into their thing.  Thank you, and
we'll turn it over to John and to John.  
              John Curran:  Come on up, John, and give the transfers update
that we didn't do earlier.
TRANSFERS UPDATE 
              John Sweeting:  Good morning, everyone.  We'll get this done
and get you off to lunch.  
              So these are just some statistics on transfers that we always
feel are interesting to the community.  And we're going to do the number of
completed transfers, transfer processing time, number of IPs transferred and
the size of the blocks that are being transferred.  
              So much to everyone's surprise, transfers are increasing.  The
number of transfers are increasing.  Here you can see the -- it's a pretty
steady increase. 
              The in-region through the last two years have stayed pretty
much steady.  
              M&As have gone up, but a lot of that is because there's M&As
required to then go and do the specified transfers.  So that's what -- a lot
of that is legacy space that has to be updated to their legal successor so
they can actually do the specified transfer.  
              Processing time is decreasing.  We're getting better at
processing transfers, which should be good news to the people that are
involved in that.  I know Mike's shaking his head back there.  So that's
good.  
              Inter-RIR transfers, number of IPs.  Over the three-year
change, there's been 15 million IP addresses involved in the inter-RIR
transfers from ARIN to the other two regions that we're involved with for
inter-RIR, which would be RIPE and APNIC at this time.  
              You can see the difference there, 2016.  If you remember in my
last presentation, I don't know what it was about, but in there I told you
that the number of IPs within the transfers depends on some of the larger
transfers happen during certain years.  
              So in 2016 we probably had a very large transfer.  In 2017 we
probably didn't -- we probably missed those larger transfers.  And then in
2018 we had significant number of large transfers.  So that's the difference
in the number of IPs.  
              In-region transfers.  You can see it was pretty steady, 2017,
2018, even though the number of transfers did increase.  
              M&A transfers, as it indicated on the couple of slides back,
2018, we have a significant number of M&As.  And, again, that's due to the
legacy space that has to be merger -- the 8.2 merger and acquisition process
to get it to the legal successor that can then do the specified transfer. 
Almost exclusively that's the reason for that.  
              So most specified transfer blocks are small, as you can see. 
Contrary to what I think is the belief, there's a lot of /24s being
transferred.  As you go down and you look through it, the next significant
-- well, there's 23s, 22s -- but then you go down and you see /16 is the end
of the larger block; /16 is the most prevalent block size that is
transferred.  
              I guess I could make one comment on it, as you see, there's
four /10s.  Sometimes that is a larger block that's sold in increments or
transferred in increments over time.  
              So summary, number of transfers are increasing.  Processing
time is decreasing.  The transfer activity is increasing the LRSA coverage. 
That would be the 8.2s that are increasing and the number of IPs that are
coming under agreement with ARIN.  
              And most specified transfer blocks are smaller blocks.  So
it's not just the -- the big effect on the market is the big transfers, but
there are a lot of small players going out there and getting their required
resources on the transfer market.  
              That's it.  Questions?  
              Kevin Blumberg:  Kevin Blumberg, The Wire. Really quick.  Is
it possible to get statistics at some point for, ISP and end user separated,
on the percentage of ARIN users that are doing transfers both out,
completely out, and as well taking in resources, because I think it would be
useful to know 8 percent of ISPs are getting new resources through the
transfer process, and 48 percent of end users are getting them through -- or
whatever the numbers may be, and 14 percent of all end users have
transferred space out, things like that?  
              Those two sort of in-and-out scenarios in terms of the total
number of members. 
              John Sweeting:  Absolutely.  What we want to do here is
provide the community with the statistics that they're interested in in
accordance with the transfer market.  
              So if I could ask you or anybody else a favor that anything
you would like to see reported on at the next meeting, see me or shoot me an
email, give me a call, whatever, and we will make sure we get those
statistics and we present them to you at the next meeting.  
              Kevin Blumberg:  Thank you.  
              John Sweeting:  Anything else?  
              (No response.)
              Okay.  That's it.  
              John Curran:  Thank you, John.  
              (Applause.) 
              Okay.  Let me now wrap us up so we can get to lunch.  Okay,
brief announcement.  There's lunch table topics.  So when you go out there,
if you want to talk about, oh, things like transfer policy or IPv4 Waiting
List or joining the AC or PPML participation or Whois database cleanup or
training at ARIN, find a table.  There's people interested in that topic. 
              The RSD help desk remains open.  So if you have questions for
RSD, registration services, go out there.  They can help you resolve
whatever process you're trying to do.  
              Take your valuables with you.  This room is not looked and
we're going to have -- we're all going to be eating so there will be no one
here to watch anything.  
              So we resume promptly -- it's a quick day -- we're resuming
promptly at 1:00 p.m.  See everyone back here, 1:00 p.m.  
              [Lunch Recess taken at 12:00 p.m.] 
              John Curran:  If folks will come in and be seated, we'll get
started.  Welcome back, for those who made it back.  I have a funny feeling
I'm competing with beach chairs.  
              So I'd like to welcome everyone back from lunch.  We're going
to continue with our policy block.  The next discussion is about a range of
policies all having to do with Section 4.8.1 and the waitlist section of the
NRPM.  
              To introduce this, I'm going to have Rob Seastrom come on up. 
Come on up, Rob.
ARIN-2019-6: LONGER HOLD TIME REQUIREMENTS FOR 4.8.1  RECIPIENTS 
              Robert Seastrom:  Hi, everyone.  So for a little bit of
background here, for anyone who hasn't been paying super close attention,
the ARIN Board of Trustees suspended grants from the Waiting List at their
meeting in January.  
              This is a really unusual action.  The Board is not given to
undertaking emergency actions lightly.  In fact, I can only remember them
doing it twice before.  
              The point of concern here is that there was action unevenly
distributed through the different ranges of blocks, where larger blocks
seemed to get mysteriously sold on as soon as they were eligible to be
transferred at a much greater rate than the smaller blocks.  
              At its annual face-to-face, the ARIN AC was advised of this
suspension and the minutes weren't out yet, but we immediately set to
curating a list of potential things that we could do about this through the
policy process.  
              Nothing was considered off the table or too out there.  It was
basically a brainstorming effort and then we distilled it from there.  
              The Board published its minutes and as early as February 8th,
there was a proposal from the community.  The AC published its menu of
policy actions on March 7th and there were subsequent and complementary
proposals that came from the community.  
              So this is not a Policy Proposal.  This is a bunch of possible
policy actions.  But for the problem statement -- we figured that we needed
a problem statement anyway -- what can we do, what is the best action or
combination of actions to take in order to minimize opportunities for
windfall profits and incentives to manipulate or make misrepresentations to
registration services related to the Section 4.8.1 Waiting List?  
              I have a slide here for each of the potential policy actions. 
This is basically a restatement of what we posted to PPML in March.  Actions
that have a policy in play that is in that space are color-coded green. 
They have a plus next to them.  Actions that the AC considered suboptimal
are blue with a minus after it.  
              But one of them got changed based on feedback on PPML.  It is
now green.  Actions that have not gotten support as far as a Policy Proposal
and have not gotten the hairy eyeball are black and white.  
              Are we ready?  Let's go through the list.  Overarching concern
here.  If we change the criteria or how much you can get or other attributes
of it, what happens to the organizations that have already justified space
through Section 4 and are now on a Waiting List?  
              And there's a bunch of things we could do with that, and
there's no firm answer that's made itself clear yet.  There probably will be
once we figure out which policy proposals get traction.  
              Here's one of the possible policy actions we could take. 
4.1.8 space would go to the replenishment pool for critical infrastructure
or transition space.  
              There were comments to the effect that this was a good way to
serve new entrants and that it would create a larger pool of small blocks
for this.  Unfortunately, it does send the wrong message about the future of
IPv4.  
              Another possibility, since we're trying to get rid of windfall
profits, one of the things we could do is take away some of the money on the
input side, meaning ARIN would charge a fee involved with these blocks at
issuance time, and after that it would be under a standard RSA.  
              We considered that possibly more fair than just putting the
space on the market.  But there were multiple folks on the AC and privately
who said to me, you know, if this Policy Proposal change that we do favors
anyway or creates an uneven playing field, it really ought to favor those
who are otherwise unable to participate in the market in a meaningful way. 
And this would certainly pull the rug out from under organizations that had
no money.  
              Another possibility was to make 4.1.8 space untransferable. 
Unfortunately, we considered this to be bad in terms of Whois accuracy,
because it would basically put something -- it would potentially give rise
to just backdoor transactions and not being reflected in Whois.  
              But it does reduce the incentive for fraudulent application
with the notion of profiting on it.  If you can't pass it on certainly the
value is reduced if one's just signing an LOA.  
              Other folks have told me that, you know, you probably are
painting the devil on the wall here with this underground market.  And it
may not be as high as you think it is.  
              A more gentle version of this is to create a longer hold-down
period after receiving 4.1.8 space.  Currently you have to hold onto it for
a year before you're eligible to transfer it on.  
              There is a Policy Proposal that proposes a hold-down period of
24 months, which is 2019-6.  So that is currently in play.  Another possible
policy action was only one 4.1.8 application per applicant.  
              The big difficulty to this is that spinning up new corporate
entities is something that I sometimes think that the business side of my
organization does just for fun because they're bored.  
              It's $150 to [dull a] registry and then you're off to to the
races with with a new set of corporate papers.  So it is a higher impact on
folks trying to game the system.  It sends a good message about new
entrants.  
              Unfortunately, it may not actually have the effect that we
would like it to.  
              Another possibility that was floated is no 4.1.8 resources for
any existing IPv4 number resource holder.  It's a variant of no getting back
in line.  The Waiting List is for new entrants.  
              Another officer attestation at the time of being placed on the
Waiting List.  This is not something that we can say via the Public Policy
process, but we can certainly suggest that the Board consider implementing
and discuss with council if this creates friction or a sticky surface for
things that rise to the level of fraud, then that could potentially be a
good thing outside of the Public Policy process.  
              Another possibility, this one is in play.  This is the general
action here.  I have slides for the specific prefix lengths after this. 
Generally everyone I've talked to and all the discussion on PPML suggested
to me that this would be part of any comprehensive solution.  Right now we
don't nail it down and there are folks in line for up to a /16 on the
Waiting List.  
              What's the particular implementation?  Why don't we just make
it a /24?  After all, APNIC just made it a /23, right?  A /24 serves the
most organizations, creates more grant events for registration services to
be able to discern a pattern.  Gee, all these organizations have the same
P.O. Box.  Geez, is there something weird about that?  RIPE is discussing
doing this. 
              Unfortunately, it also maximizes the number of organizations
that get less space than they could otherwise justify.  How about make it a
/22?  
              There are no or substantially no questionable applications at
this size under current policy.  The fixed costs of doing the transfer are
sufficiently high that they eat into the project margin for selling /22s
onward.  
              This would server a greater diversity of organizations than
just a /24.  Everybody brings up RIPE using /22s, and the externalities
they've had there.  I'd like to point out we're not talking about getting
rid of needs basis.  
              We're not saying anybody with a corporate entity who says I
want to be an LIR, you're going to be an LIR and get a /22.  
              I don't anticipate that to be a problem if we go to a /22. 
This is proposed in ARIN 2019-2.  Well, how about a bigger chunk then?  21
or a 20.  
              There's still no or substantially no questionable applications
under today's policies.  That's 16 times the payout for selling it on, but
it's a cut of a factor of 16 for -- compared to a /16 if somebody was
justifying the space with the idea of selling it on.  
              The AC talked about this and said, you know, this only moves
the goal posts.  And cutting it down by a factor of 16 is not sufficient to
keep a lid on gaming the system.  
              So there's some things that the AC thought, gee, bad idea;
we're just not going to do this, or we're not going to suggest this, is no
longer issue 4.1.8 space.  In other words, continue the 4.1.8 indefinitely. 

              This is basically equivalent to eliminating the Waiting List
except it's on the output side.  You could continue to applying for Waiting
List space as long as you want to.  We're just not doing it.  
              This would have the bad effect of, you know, ARIN gets back a
lot of space.  They get it back primarily from organizations that don't pay
their bills.  
              If you're out of compliance because you haven't paid your
membership fees, space goes back.  
              Oddly enough, there's some organizations that hand back the
space.  And nobody was more surprised to hear this than I was.  But some
organizations said, well, you know, yeah, sure, we know we could sell it on
but it's -- getting the money would create a problem for us, so just please
take this back.  
              ARIN gets enough space back that this is really not where we
want to go with this.  
              How about on the entry side.  We fill the applications that
are already in and then we're done.  Close down the entry side of 4.1.8. 
This is basically the same thing as getting the entry of the Waiting List --
still the same problem, the stranded space problem.  
              How about if we prioritize not-for-profit organizations. 
They're all doing God's work, right?  
              Well, the problem is that that status is an artifact of
national tax laws wherever you happen to be. 
              Not-for-profit and good work shouldn't be conflated, and it
says nothing about your size or budget.  And it would be difficult to
implement across the entire service region.  
              How about we go back to business as usual?  Maybe we as the AC
just say, well, you know, Board, do whatever you want here.  Maybe the Board
should just unsuspend it and keep on going. 
              We didn't think this had legs for obvious reasons.  So
distributing 4.1.8 space via the transfer market.  This is a little bit of a
surprise to me.  
              AC members and folks outside the AC who have been in the
community a long time that I talked to said, man, the optics on that are
terrible.  Everybody is going to think that ARIN has an incentive to yank
back address space.  The community will never support this.  
              And yet when the discussion of the /22 came along, what was
the number one comment I saw?  It was why are you doing this at all; you
should just be selling this. 
              There's a transfer market.  Sell the space that comes back. 
So distribution of reclaimed addresses in an orderly fashion via the
transfer marketplace is proposed in 2019-7.  
              Another possibility which we rejected because it was even less
a wobbler than the /21 was a /19 or a /20.  This would just move the
goalposts incrementally and probably not result in any kind of serious
reduction in the number of questionable applications.  
              So here's a summary of all the possible things that we've
discussed.  No doubt some folks in here are looking at some of the black
ones and saying, you know, I think that sounds like a good one.  AC members,
hands up.  AC members.  Look around you.  
              If you don't know how to submit a Policy Proposal, we are
around.  We're all around you.  We're at your service.  We can help.  
              So that's the end of the slide deck.  
              Paul Andersen:  So this is technically a policy block.  But I
would note that one of the complications we have is that while the AC has
done great work, and the Board thanks you and the entire AC for doing this
excellent summary, there have been other proposals that are on the agenda
today that have been injected by members of the community. 
              I guess if there are questions it would be best if they were
left at high-level concerns or support noting that we don't want to get into
the specifics of policy text that we're discussing later, if that's possible
to wait to that point.  
              Robert Seastrom:  All right.  Owen, go ahead.  
              Owen DeLong:  Owen DeLong, ARIN AC.  Stop accepting
applications for 4.1.8 is actually worse than no longer reissuing 4.1.8
space, because it doesn't trap the space at ARIN. 
              Instead, it creates a timing lottery where if you get your
application in first right after ARIN gets the space ready to re-issue you
win.  If you don't, you lose.  
              And I think that would be substantially less fair than
trapping the space at ARIN actually.  So I would really hate to see that
happen.  
              Both of them are on the nonstarter list so that's a good
thing.  I would actually like to see a combination of reducing the maximum
issuance and increasing the hold-down timer.  I think that's probably our
best bang for the buck without doing too much unintended damage. 
              Robert Seastrom:  Thank you.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. I'm not going to
talk to the proposals that are there.  We'll do that at that time.  
              I want to talk about policy versus RSA because I think it's
critical to this overall discussion.  If somebody gets space through policy
that is accepted and then two years later transfers that space, the fact
that the space was not used for its intended purpose really, the space can't
be returned.  They thought about using it for the right reason and then they
decided not to.  
              You can't really prove it was fraud.  So the RSA doesn't have
a revocation for policy abuse.  It has some very specific requirements. 
              And that is a problem because there was one policy that I want
to use where we looked and envisioned this abuse scenario which is the TPIA
policy.  If you look at the TPIA policy, it says that an M&A transfer may
not occur unless it's for intended purpose of what that block was in the
first place, because, quite frankly, a 22 or whatever size it is, it doesn't
matter the size, it's irrelevant, if I can get space from ARIN, wait seven
days and decide my business model has changed, lease that space out for two
years, I am going to make money at it.  
              And then I can turn around and sell it on top of that and make
money on it.  And whatever numbers you have here are not relevant.  
              There will always be a way to make profit.  So unless you can
take that away through either the RSA or through some teeth in our policy
manual that directs staff to use the RSA to treat something as what is
equivalent to fraud from the RSA's perspective, none of this is going to
make a matter because we've gone through this in all the other regions. 
              Paul Andersen:  John would like an opportunity on that. 
              John Curran:  So, if you would like to make it so that people
do not use the space issued via the waitlist queue except for the purposes
intended, then you can tell them, tell us in policy this block is to be
issued and is nontransferable and if not used must be returned.  And that
will solve the problem.  People will not monetize those blocks.  
              If we catch people doing it and we have people who do
creative, like, cross-lending of address space, we take it back.  It's easy
enough to take back.  
              And people will know they don't want to be on that address
space because we'll take it back and reissue to someone else waiting for it
because there's a queue of people waiting for it. 
              So you can create the issuance of address space which is
nontransferable, and it will be nontransferable.  And it doesn't need
anything in the RSA and it's 100 percent enforceable.  
              Be careful if you're going to do that that you're very clear,
these blocks being issued are nontransferable.  
              Kevin Blumberg:  That's not what I'm looking at.  What I'm
looking at is the concept of as long as the block was used for its intended
purpose originally, after X time, if things do change, then that's fine.  
              But this issue is people are getting the blocks, using them --
and we're seeing this in the other regions and that's why their policies
changed -- leasing out the space, not using for its intended purposes and
then waiting the three years or whatever and flipping it.  
              John Curran:  So the problem is if you want to decline an M&A
transaction. 
              Kevin Blumberg:  Right. 
              John Curran:  The M&A occurred -- we're back to record
keeping, okay?  Other company bought your company.  They may have bought you
for the address space, but they did buy you.  And so us not recording that
is very difficult to do because you're consciously saying you don't want to
record what is an actual transaction.  
              The rights almost certainly legally have transcribed.  If we
get into a situation where that subsequent entity goes bankrupt, I am going
to be facing a bankruptcy judge who says, I bought A, he had these
resources.  Show me why they did not transfer.  
              And so you've got -- we don't have perfect insight into
requesters, the state of the mind and the state of their business.  
              When they come back and say we used it for a while and there
were changing circumstances, ARIN is generally flexible in this regard
because the alternative is bad record keeping.  
              I'm not sure, unless you've got, if you want us to polygraph
people, I'm not sure we can go back retroactively and say you did this
entirely to get address space.  
              Paul Andersen:  Could we do that, could we polygraph people?  
              John Curran:  I can do whatever the Board likes.  
              (Laughter.) 
              Kevin Blumberg:  I think that's the message for the community
is ultimately once this space is given out, there's a clock ticking or not
depending on what the community wants and we need to make that decision.  
              But once that space has been given out based on the policy, if
we allow a transfer in two years, then a company is perfectly, legitimately
allowed to do that. 
              Paul Andersen:  So we have about five more minutes in this
block.  If you want to approach a mic make a comment, please approach now. 
And if those that are at the mic could be as succinct as possible, thanks.  
              Michael Casadevall:  Michael Casadevall, NARALO.  From where
I'm standing, from this list, the only way you're going to prevent gaming of
the list is by disallowing transfers and then looking at a very critical eye
at mergers and acquisitions, and basically be at a point where you're going
to reclaim space if M&A happens and so forth and so on.  
              I know it's really easy to make multiple corporate entities
trivially.  But the 4.1.8 space is basically what's left of v4.  We should
still be able to issue it without people having to go to the secondary
market.  
              And I think we need to look seriously at what we can do from a
legal point of view to limit how address space can be abused in transfer or
mergers or acquisitions.  
              In saying that, the address space must be returned to ARIN and
then granted a waiver to be returned during M&A, may be the way to do.  That
would help reduce the gaming quite a bit from this address space, by putting
restrictions on it in addition to nontransfer.  
              Paul Andersen:  Who's next?  Kerrie. 
              Kerrie Richards:  This question is from Jason Schiller,
Google, ASO AC.  Can ARIN staff pull together stats for all Waiting Lists
larger than a /21 that are still waiting?  Choose to take less and are not
waiting, how much less -- half quarter, one-eighth; took a transfer and are
not waiting; withdrew from waiting or got what they asked.  
              Paul Andersen:  I was just wondering because obviously
[(indiscernible)] maybe we could just provide that comment to John Sweeting
and he could -- 
              Robert Seastrom:  I was going to say, indubitably, John can
get some sort of statistics and have Jason send over the specifics so he has
that in front of him.  You got it?  Perfect.
              Paul Andersen:  Microphones are closing soon. 
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  So
going back to the 4.1.8 allocations that were flipped, that were recognized,
that resulted in the suspension in January, in retrospect, obviously you're
not able to say anything specifically about those transfers, but is there
anything in retrospect in those transfers that looked kind of hinky?  Has
there been any retrospective to figure out, okay, is there something that we
can look at in the request that may or may not allow us to better catch
these types of requests in the future?  And could this just be solved by
increased scrutiny?  
              Paul Andersen:  John. 
              John Curran:  There was a number of tactics used that we
cannot overcome.  They involve fraudulent representations well-crafted and
next to impossible for us to detect.  
              And so in that regard, no, it's a problem and it's a
significant problem.  There's costs involved in doing it.  Those costs are
relatively high.  
              And so very large address blocks enable that type of fraud in
a way that's very problematic, akin to someone coming into the meeting with
plastic surgery who looks like me moderating the mic, you might have a
problem overcoming that if someone wants to put a years work in of
preparation.  
              We have advanced people who have decided to do some very
aggressive schemes.  And so we're dealing with it.  There are other lessons
learned from other cases, and we do incorporate better scrutiny.  
              But recognize if there's a large financial incentive, people
will do things that you would think not reasonable to attempt to pull one
over on ARIN.  
              Paul Andersen:  Last call for microphones.  The microphones
will be closed after this comment, so approach the microphone immediately,
please.  
              Kerrie Richards:  This is from Brian Jones, Virginia Tech, I
support 2019-6 at least in principle for increasing the length of wait
times.  
              And I have another question from Jason Schiller, Google ASO
AC.  Can we get a sense of how?  
              Paul Andersen:  How?
              Kerrie Richards:  Yeah, I'm going to ask him.
              Paul Andersen:  I'd ask Brian obviously if it is possible he
could make the comment during the 2019-6 block and -- any chance you're
getting more -- 
              Robert Seastrom:  The answer to "can we get a sense of how?" 
The answer is clearly maybe. 
              Kerrie Richards:  How long the wait time the community would
tolerate.  If it's different, if it only includes specified transfers. 
              Paul Andersen:  Could you read the whole thing together?  
              Kerrie Richards:  Right.  He said, can we get a sense of how,
and then he followed up by saying how long a wait time the community would
tolerate.  Is it different if it only includes specified transfers?  
              Robert Seastrom:  I did not manage to get the discussion of
that into there.  There was a question of 8.2 versus 8.3 transfers and what
ought to be done.  And I don't see -- I personally, as sort of the curator
of this pile of possibilities, see them as two very different things -- 
              Paul Andersen:  Owen, directly to the point just raised.  
              Owen DeLong:  I think there's definitely a distinction between
what we would want to accept in terms of rules regarding 8.2 transfers
versus 8.3 or 8.4 transfers.  And I would strongly suggest that the 8.2
transfers might incur a shorter waiting period than 8.3 or 8.4.  
              Paul Andersen:  Thank you.  Microphones being closed.  Over to
you to finish off. 
              Robert Seastrom:  I have nothing further.  Thank you very
much.  
              (Applause.) 
              John Curran:  Okay.  We're going to move into the next policy
on the list, which is ARIN 2019-2:  Waiting List Block Size Restriction. 
And Alison Wood will come up and give the presentation.  
ARIN-2019-2:  WAITING LIST BLOCK SIZE RESTRICTION 
              Alison Wood:  Hello everyone.  I'm Alison Wood, and this is
Draft Policy 2019-2: Waiting List Block Size Restriction that you heard just
a little bit about in R.S.'s talk.  
              So, shepherds on this policy are myself, Alison Wood, and you
can recognize him by the bitmoji, Andrew Dul.  There he is. 
              I do want to give a shout-out to my Copacabana volleyball
team.  We fought a good fight last night.  Wendy stacked her team with some
professional volleyball players.  I don't think that was fair, but we'll
move on.  
              So, as you all know that the waitlist has been suspended, and
this proposal is an attempt to minimize the abuse in the free pool.  
              I know there's a lot of waitlist experts, free pool experts in
the crowd, but we did have a lot of newcomers.  So just forgive me while I
back up a little bit and talk a little bit about the free pool.  
              So an organization can apply for IP address space from the
free pool.  They'll be put on a Waiting List, and the minimum that we dole
out is a /24.  Today, as R.S. mentioned, there's no maximum.  So we do have
people sitting on the waitlist waiting for a /16.  
              They are granted that IP address space when it comes
available.  So people requesting smaller blocks usually get their space
before the people who are requesting larger blocks.  But they still get
their space.  
              So the summary of this Policy Proposal or Draft Policy is that
the maximum size that we dole out on the free pool is a /22.  If an
organization comes in and requests a smaller size than that, then obviously
we would go with whatever is smaller, the /22 or what they qualify for under
the ARIN requirements.  
              So this is the current text with the update in blue and
underlined.  And, again, so what it says is today an organization can come
to ARIN.  If they meet requirements, they get the address space that they
request over time.  
              And the update to the policy would state that the most that
they can get is a /22 if they meet their requirements.  
              This I pulled directly from the PPML.  These are comments that
came back from you, the community.  And I hope they will instigate some
discussion.  
              So pretty much limiting the maximum block size to a /22 will
decrease the financial incentive by the bad actors out there.  The majority
of Waiting List requests are for smaller block sizes, so by eliminating the
fraudulent activity and also reducing the block size, that should allow
people asking for smaller blocks to get their IP address space quicker.  
              Okay.  So what we learned today is that APNIC does dole out a
/23.  So my slide is incorrect.  But RIPE and LACNIC will give out /22s out
of their last /8s.  If we switched our policy to be a /22 we would be in
line with RIPE and LACNIC.  
              And let's see, organizations that generally need larger blocks
can obtain those blocks on the transfer market.  
              Oh, I turned it off.  That's okay, I have it memorized. 
Practiced after volleyball.  Thank you.  
              So for discussion, please feel free to come to the mics and
discuss anything you'd like with this policy.  Happy to answer all of your
questions.  However, I'd love to know if you support the suspension of the
Waiting List, if you feel that a /22 is the appropriate size block or if you
would like to see different sizes.  And I don't know if other restrictions
that should be applied are appropriate in this policy block, but I'm more
than happy to answer and address your questions and comments.  
              Paul Andersen:  A little preface as the guns line up at the
microphones.  If you've looked at the agenda, you've seen that there is
several policies that are all related to this waitlist.  So I'd ask the
comments be directed to whether you're in favor or against this policy and
try and avoid other policies when the block comes up. 
              We do have some open microphone later.  So if after, later you
want to try to bring back some items we can always address it there.  But we
generally, for the idea of a fluid policy discussion, try and deal with the
matter on the table, which is 2019-2.  
              So with that warm-up preamble, I'll ask if there's anybody who
wants to speak.  Wait, look.  There's tons of people.  Just to throw it off
a little bit, we'll go to the side microphone.  
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  I
support the policy as written.  I believe that suspending the Waiting List
was the right thing to do under the circumstances.  
              I believe that this policy would not be the only mitigation I
would like to see be put in place before the Waiting List allocations are
resumed.  
              Paul Andersen:  Thank you.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. I support the
suspension of the waitlist.  That's the first thing.  I support the intent
of this proposal.  But this proposal is not enough unto itself to then allow
for the waitlist to be brought back.  
              The 22, I believe, is the right size.  It's very consistent
with other regions.  I don't think right now it makes a difference whether
it's a 22 or 23, but I think that's fine.  
              In looking at the other regions, the disincentive financially
has been because of their fees yearly for these services.  As an end user,
once you've gotten it, the fees are very low.  
              One of the things to considering is possibly only allowing the
waitlist to go to RSA, Registration Services Agreement, people, who are then
having to pay for these services every year to maintain them.  That would be
a very big disincentive, very similar to the other regions, like I said.  
              I would like to see it either under no transfer or under a
long waitlist, three to five years, similar to what APNIC has just looked
at.  
              Again, there has to be something other than just /22 for me to
support opening the waitlist back up.  
              Alison Wood:  Okay, thank you. 
              Paul Andersen:  Back to the middle microphone.  
              Owen DeLong:  Owen DeLong, ARIN AC.  Could we go back to the
slide to the questions for the community?  
              I would support reinstating the Waiting List if we address the
issues that were raised by the Board when they suspended it.  
              I think 22 is fine.  I'm actually fine with anything 21 or
longer as being a perfectly valid size to do this.  
              I do think we need other restrictions.  I would like to see at
least a strong 24-month waiting period for transfer with a possible
exception for M&A, but I'm not completely sure I want to make an exception
for M&A.  But we can discuss that under other policy proposals.  So I'll
leave it at that.  
              Paul Andersen:  Thank you.  Back to the side.  
              [Joe Provo:  Joe Provo], ARIN AC, Google.  Speaking for
myself, yes, I wish we could go smaller but I don't think we could.  And
most definitely yes.  I will speak to the other policies when they are up.  
              Paul Andersen:  Thank you, middle microphone again.  
              David Farmer:  David Farmer, University of Minnesota, ARIN AC.
 I support reinstating 22 -- like Owen said, 21 to 24, anything in that
range seems reasonable.  22 seems as good as anything.  And yes we probably
need additional restrictions.  One comment here, there was discussion of,
well, 22 doesn't completely eliminate the incentives and we're not about
completely eliminating fraud.  There's no way to be perfect in that.  
              We're looking to have a reasonable balance between
disincentivizing fraud and making sure there's no large incentives and
penalizing the good guys, penalizing the people that are doing legitimate
things.  
              So it's about finding balance, not about perfectly eliminating
fraud.  I support the policy as written.  
              Paul Andersen:  Microphones still open but we'll have to close
soon if I run out of speakers.  Approach a microphone soon.  
              >>  Barry Sherwood Great Basin Internet services I support it
              >> as written I'd like to see a 24 month waiting period and I
              >> think I prefer the word arbitrage over fraud.  Because I
              >> think it is a gaming of the system.  I don't know that it's
              >> necessarily fraud.  Somebody sees an opportunity and
              >> they're taking advantage of it and if we don't like it, we
              >> can stop it.  So there you go.  
              Paul Andersen:  Microphones will have to close after this
speaker if we do not have -- so please approach a microphone as soon as
possible if you'd like to speak.  
              Chris Tacit:  Chris Tacit, Tacit Law and ARIN AC.  I would
only support reinstating the waitlist if the considerations that the Board
identified in suspending it could be significantly lowered or eliminated.  
              Although, I take David's point that it may be impossible to
completely eliminate the problem, but we might be able to make it a minimal
issue.   
              /22 seems fine to me.  And with respect to other restrictions,
              /yes, I believe there need to be others, for the simple reason
              /that, as we heard yesterday, there's going to be economic
              /value in IPv4 address space for the foreseeable future, and
              /it's likely to increase in the next while. 
              And so whatever we do will need to be probably a multipronged
solution that calibrates itself to try and counter some of the economic
incentives.  And I'm not sure a block size is enough. 
              So I'll reserve judgment as to what might be after we listen
to a few of the other proposals and maybe discuss it after that.  But I
don't think any one remedy is going to be enough.  I think you'll need a
combination of techniques to do it.  
              Paul Andersen:  That will close the microphones after Chris. 
I'll give one extra second.  Not only will we thank you for your
presentation but we'll also explain why we keep making the joke because
broke her world record in high jump just recently.  So double -- 
              (Applause.) 
              That ends that one.  John.  
              John Curran:  We'll have Rob Seastrom up again to cover
2019-6: Longer Hold Time Requirements for 4.1.8 Recipients.  
              Robert Seastrom:  Speaking of records I'm going to try to set
a record here for a short presentation.  
              So problem statement.  We've all seen this problem statement
before.  The Board has suspended 4.1.8 Waiting List.  Minimum hold time
before you can transfer address space onward is a year right now.  The
author says that they believe the longer hold time of 24 months is
reasonable.  
              Policy statement to do same.  And put 24 months in the NRPM
where there is currently 12.  And there's been no discussion on PPML even
though it has been sent to PPML as a draft -- there's one -- none sent to
PPML as a draft and the fact that the AC took it on to their docket was
posted to PPML.  
              So questions, discussion.  
              Paul Andersen:  Barely sat down.  Microphones are open once
again.  Looks like you'll get a little -- well, he's just running away from
me.  Okay.  Well, thank him for his very quick presentation and we'll open
the microphones in the front middle again.  
              Chris Tacit:  Chris Tacit again.  This is another one of the
factors that I think ought to be considered, duration.  I seriously doubt
that two years is going to be sufficient given the extended time during
which IPv4 address space is likely to be valuable. 
              I think you're going to need to see a much longer period for
people to start thinking twice about not sitting on these things or leasing
them in the meantime and then doing the transfer at the end of whatever that
period is.  
              Paul Andersen:  You're in support of this -- if I understood
you correctly you're in support of this initiative but maybe -- 
              Chris Tacit:  As one potential piece.  But I don't think it
does it all.  And the duration not quite long.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. I would support the
Advisory Council merging this policy with the policy before it, taking this
one salient point from this problem statement, which is to increase the time
and making that a factor of the first proposal, which is more important. 
This is a secondary control, not a primary control.  And I agree with the
previous speaker, 24 months is not enough.  
              I believe we need to look at the other regions and all the
issues they've had over the past three years because they've had
significantly more issues than us based on their pools and look at three or
five-year things based on feedback on the types of abuse that they saw in
those regions. 
              Paul Andersen:  In support of the problem statement,
effectively?  
              Kevin Blumberg:  In support of the problem statement.  
              David Farmer:  David Farmer, University of Minnesota, ARIN AC.
 I like the idea of merging this with the other proposal.  
              I would be concerned with approving any of them on their own. 
I think we need to have a consolidated solution. 
              I support the problem statement it needs to be longer.  I
agree that 24 is probably not long enough, maybe start with 36, anything 36
to 60 months seems reasonable.  I'll leave it at that.  Oh, I do support the
problem statement. 
              Paul Andersen:  We go back and forth.  If you want to get in
look for the shorter line.  
              Barry Sherwood:   Barry Sherwood Great Basin Internet
services, I support combining it would go be good.  24 months minimum.  I
said 24 months earlier 24 month minimum. 
              Owen DeLong:  Owen DeLong, ARIN ACI support the extension of
the waiting period as mentioned earlier.  I'm perfectly fine with David's
suggestion of 36 to 60 months as valid targets.  I am not sure that when
combined with the smaller prefix size this wouldn't do it. 
              People talk about comparing to the experiences in other
regions.  I would like to point out that no other region has experience with
a Waiting List, the other regions experiences are with issuance from their
final /8s primarily, not with the Waiting List. 
              Paul Andersen:  Good distinction, thank you.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. One additional
comment.  Our routing policy says that ARIN does not guarantee that the
route that you get is globally routable.  
              Paul Andersen:  Correct. 
              Kevin Blumberg:  One other suggestion is to basically put into
this or whichever policy it is that space issued under the Waiting List is
not guaranteed to be transferrable and basically allow the community to
revoke at any time transfers if they feel that abuse is there but to
actually spell it out that you can get space here but don't expect that at
some point that might change.  Let people know in advance.  
              Paul Andersen:  Maybe I misunderstood.  When you say the
community maiden a transfer you mean may change the policy on you?  
              Kevin Blumberg:  That things may change in the future. 
              Paul Andersen:  Not that the community would suddenly approve
every transfer. 
              Kevin Blumberg:  No, no, no.  The Board suspended this policy
for a very good reason.  And I think that somebody coming to the Waiting
List a year from now is not necessarily going to know the history that we
all know, and putting in there that at some point the Waiting List -- again,
M&A's I'm going to separate out not potentially a windfall you may not be
able to transfer at a later date. 
              [CHK]:  John, would you like to speak?  I saw -- 
              John Curran:  Why would you not say space issued via this
policy is not transferrable, period?  
              Kevin Blumberg:  I would be happy with that. 
              John Curran:  You just said might not be at a later date.  The
real challenge we have is that it's pretty easy to tell someone we're
issuing you space it's not transferrable.  It's a lot more challenging to
issue them space and then you guys do something in the future and then we
have to go back to people and have space and they say they made your space
issued not transferrable, that opens up a discussion about changing the
rules out from under them. 
              Kevin Blumberg:  That's why I was saying to document that the
space may or may not be transferrable. 
              John Curran:  Why maybe, why have that?  Why not just say it's
not. 
              Kevin Blumberg:  Okay.  
              John Curran:  That's my question.  You keep saying "may be
transferrable". 
              Kevin Blumberg:  The only reason is metrics on abuse if those
met restriction aren't met -- 
              John Curran:  It's far better to prevent transfers. 
              Paul Andersen:  Please approach a microphone if you'd like to
comment.  We're running out of speakers.  Sir, you look like the person that
was standing here a second ago.  
              Robert Seastrom:  I was.  But down here I'm not speaking on
behalf of my employer because I don't have one this week.  And I'm not
speaking as the shepherd for this, I'm speaking only on my own behalf.  
              And there are two points I'd like to raise.  One is I think we
should pass two proposals that do two different things and I think we should
merge these proposals that are at odds with each other.  And many years ago
we had someone who was in the community who was fond of omnibus proposals
that have a lot of stuff in them. 
              And merging the proposals, unless there's a good problem
that's being addressed by that, makes something that's actually harder to
get consensus on.  
              Paul Andersen:  That is true. 
              Robert Seastrom:  And I believe that either making it a longer
prefix or increasing the hold time is by itself an incomplete solution but
that does not mean I believe we should throw together what we believe is a
complete solution, giving it to the community to take it or leave it.  
              So I'm opposed to merging this proposal with any other
proposals or any of the other proposals that are currently in with any
others.  
              So that's number one.  Number two when we talk about making it
three years, five years, 10 years minimum hold time, what we've essentially
done is made it you can never transfer it, because five years in Internet
time is an awfully long time.  And we've done a lot of work to make Whois is
more accurate.  
              One of the things we did that got a huge amount of community
support was to eliminate the audit with 8.2, so that M&A could update and
not have companies that you haven't heard of since the dotcom era in Whois. 

              I want people to think about the externalities and the
unintended consequences for advocating for a longer hold time.  I would love
to make the hold time be essentially forever.  But I temper that with the
fact that I value who is accuracy very, very highly.  
              Paul Andersen:  Thank you for your comments.  Microphones will
close after this comment.  Please approach a microphone if you'd like to
comment or start typing.  Go ahead, please, remote.  
              Kerrie Richards:  Speaking for Jason Schiller, Google, ASO AC:
 I support a longer time, including 24 months, 36 months, 60 months, or
maybe even 120 months.  
              John Curran:  That closest the microphones.  I'd thank like to
thank our presenter.  
              (Applause.) 
              John Curran:  Let's talk about getting rid of the waitlist, if
Alyssa Moore will come up we'll present 2019-7: Elimination of the Waiting
List.  
              Alyssa Moore:  So it won't be quite as short as R.S.'s
presentation, but this one's pretty brief.  And Amy Potter is co-shepherd on
this one. 
              I don't think I need to go through this.  We've been talking
about it for the last hour and a bit.  It's the background.  
              So we already all know the problem.  Unfulfilled requests
create an opportunity for ARIN members to claim need for number resources,
wait for those resources to become available via return to reclamation
acquire them wait a year and a day and profit from them.  
              And ARIN can avoid this by abolishing the Waiting List
transferring reclaimed returned resources qualified by the existing 8.3
process.  
              So the policy statement essentially says that we would get rid
of Section 4.1.8 all the way through and add a new policy section on
returned and reclaimed resources also says that ARIN will auction returned
and reclaimed IPv4 number resources to recipient qualified under Section 8
.3 revenues realized from this activity will be allocated for purposes as
directed by the Board of Trustees.  
              And the author also left us a comment that the specific
auction methods and implementation details used to distribute the returned
addresses are outside of the purview of the policy process.  So that would
be something dealt with at a later date and outside of this process.  
              There's been no discussion so far on PPML about this
particular policy.  And I'll open it up for discussion from there.  
              Paul Andersen:  Approach the microphone.  And Owen wins.  
              Owen DeLong:  Owen DeLong, ARIN ACI strongly oppose this
Policy Proposal.  There's no good that comes from this in my opinion.  ARIN
does not need the revenues from this.  It doesn't have a purpose in mind for
those revenues.  I'm sure we would find one, but in general in my experience
a large supply of revenue looking for a purpose in a not-for-profit
organization tends to lead away from goodness, witness the I can make money
fast GLD scheme.  I think this is just a bad idea on multiple, multiple
levels.  
              It would also disadvantage the very members of the community
that we're intending to serve under 4.1.8 strongly and so I think it's a bad
idea on both sides of that equation.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. I than don't
support this if we want to be altruistic return it to IANA by blocks and let
them distribute it out to regions that need it but I don't believe we do
have a need for this space this is not the way to go about it.  I have a
fundamental issue with my doctor getting a kickback for services rendered.  
              I have a fundamental problem with ARIN subconsciously or
consciously being involved in the auction process of IP space.  
              I don't need a quota system where staff are looking at things
going, well, you know if it was done this way we'd get revenue and --
exactly.  
              Paul Andersen:  Don't encourage. 
              Kevin Blumberg:  Exactly.  Perceived or real is irrelevant, it
just completely dilutes the stature that ARIN has with the global community
in how it operates and this would be a massive knock to that. 
              Paul Andersen:  Thank you.  Center microphone.  
              Robert Seastrom:  Rob Seastrom speaking for myself because
that's all I've got.  I agree with Kevin that the concerns as far as
appearances with the other RIRs is a problem.  But I also believe that this
is far from being the worst possible outcome.  If we're looking at this from
the standpoint of stopping the incentives for arbitrage or for making
misrepresentations to registration services, this does it and stops it cold.
 
              We're handing out things that have value for free.  We're not
running a charity here.  We're not for profit, but it doesn't mean we're
picking winners or losers.  
              So I think that picking winners based on an externality that
favors making misleading statements to registration services is a couple
steps away from goodness.  So I'm on the edge, I'm teetering on the edge of
supporting this as written.  Thank you.  
              Paul Andersen:  Over to the far microphone again.  
              Joe Provo:  Joe Provo, ARIN AC, Google.  Speaking for myself. 
I do not support the intent as Kevin outlined, pretty much summed that up
well.  
              If by some miracle it goes forward, I would think we need to
address the language that talks about revenue stuff that's kind of outside
of general policy discussion and. 
              Paul Andersen:  Sorry, which part?  
              Joe Provo:  The second sentence talks about at the discretion
of the board of directors, all money management at the point of board of
director. 
              Paul Andersen:  Actually as directed but I understand what
you're saying. 
              Joe Provo:  If it does move forward then perhaps that actually
should specify an earmark make it an earmark fund instead of an unspecified
thing. 
              Paul Andersen:  Okay.  Thank you for that.  Center microphone.
 Chris Tacit:   Chris Tacit, ARIN AC.  I oppose first of all I think we need
to find conditions in which we reinstate the Waiting List, but I do also
want to address the economic issue.  
              I've been thinking a lot about this, and having ARIN
essentially sell address space, I think, would be an enormous departure of
the way that the organization views IP addresses as a whole.  In many ways
it runs contrary to its history of trying to treat address space as a public
nonproperty resource.  
              It would for the specific commercial transactions involved
raise a whole bunch of questions.  
              If somebody's paying a lot of money for actually space,
shouldn't they then have an irrevocable property right to it?  Could ARIN
ever expect to be able to take it away again under any conditions?  
              So it raises a whole bunch of very complex problems that I
think would need to be thought through by the Board of Trustees far and
above policy issues associated with this.  Thank you.  
              Paul Andersen:  Thank you.  Once again we are depleting our
speakers.  So if you would like to speak on this topic, please approach a
mic expeditiously otherwise we'll close the microphones at the end of our
next comment.  
              Andrew Dul:  Andrew Dul, speaking for myself.  I will note
that there's been a number of people on the PPML who have supported this
idea, just not under this specific policy.  
              So there's more I think positive posts regarding an auction
idea on list, zero.  There have been zero under this specific policy.  
              And to the issue itself, I believe we need to provide a
financial disincentive for organizations to game the system.  An auction is
one method to provide a financial disincentive to do so.  
              I've also as discussed earlier in the day we talked about a
fee for a waitlist allocation.  I also believe that is a financial
disincentive to perform activities that would lead to potential fraud
activity.  
              So I could support both of those ideas.  I don't know the
exact best method to do that.  But I think just changing the size and some
restrictions is probably not enough to make the types of issues go away that
have caused the Board to suspend the policy. 
              Paul Andersen:  Okay.  Again, we need to close the microphones
soon so please approach a microphone.  We'll give you the last one before we
close.  
              David Farmer:  David Farmer, University of Minnesota, ARIN AC.
 My gut reaction to this proposal is bleep no.  However, I've been -- this
is a radical change and maybe this problem needs some radical change.  
              So while I probably don't support it, we need to talk about
this -- the only thing that I'd say is before I could even possibly support
this, I would need to have a better idea of where the revenue goes.  Just
creating this pile of money without knowing what's going to be done with it
seems like a horrible idea. 
              Paul Andersen:  Yeah, that would be obviously out of the scope
of the policy.  It's tough.  Normally the Board would not weigh in on it nor
am I suggesting we will now in a policy in draft but if it was to a policy
like this was to progress, there would be staff analysis, legal analysis and
we'd probably I'm sure have a lot of questions about that, too.  
              We're going to close the microphones after this speaker.  This
is the last one.  Please get in the line if you want to speak.  
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  When
thinking about this problem more, I remembered that in the US the FCC
auctions off bandwidth radio frequency.  
              This feels very similar to that process in a lot of ways.  But
that itself is not a great policy in many people's opinion.  It really does
allow the space to be consolidated in ways that I don't think ARIN wants to
see the v4 address space consolidated. 
              So I think there's been some arguments towards similarities to
that but we should -- I would caution against making that type of analogy.  
              Speaking to the point Dave mentioned is that, yes, we would
definitely want to understand more about where the revenues would go.  But
that conflicts with the guidance that financial discussions and financial
directives are explicitly outside the NRPM.  
              I don't have a good answer on how one would resolve that.  If
someone has suggestions, I'd like to hear it. 
              Paul Andersen:  Microphones are now closed with the last
speaker from John Sweeting. 
              John Sweeting:  John Sweeting with ARIN.  I'd like to make a
couple points about the waitlist suspension that I'm going to cover in my
department presentation tomorrow.  But since there's a lot of people here
and we're talking about the waitlist.  I want everybody to know so the
waitlist suspended a very specific portion of the waitlist.  So it was the
distribution from the waitlist.  We are currently accepting processing
approving placing people on to the waitlist in accordance with how we put
them on the waitlist. 
              The only thing we're not doing is we're not distributing from
the waitlist.  However, we are still doing all the internal procedures that
we do to get ready to distribute from the waitlist.  
              So once there's a policy in place that allows us to do that,
we are ready to do that following that policy.  The only other thing I'd
like to point out is part of that policy that was suspended was that if you
get something off the transfer market, you get removed from the waitlist. 
That's suspended.  
              If you go to the transfer market to get through this period,
we are not removing you from the waitlist.  However, you will have to answer
to any space you get and show that you still qualify for whatever space
we're going to issue you. 
              Paul Andersen:  Thank you for that clarification, John. 
That's handy.  And thank you Alyssa for the presentation.  
              (Applause.) 
              So I know that we kind of -- we first had the general summary
discussion then each individual.  We do have an Open Microphone later if you
had thoughts on earlier proposals, that would be the good time to bring that
up.  But otherwise, I will turn it back to John.  
              John Curran:  So we're going to continue our trend of pulling
things up in the meeting so we get out earlier.  
              To that end, we have finished the policy block and the next on
the agenda is global reports with Axel Pawlik coming up for the RIPE NCC.  
              Axel Pawlik:  Good afternoon, people of ARIN.  My name is Axel
Pawlik.  I'm the admission director of RIPE NCC ARIN's cousin organization
in Europe.  It's moderately warm and rainy.  So I'm grateful for the chance
to be here today because I like it cold. 
              Reminds me of Siberia in here.  
              (Laughter.) And we have the RIPE NCC must today so some of my
colleagues are over there.  I think it's warmer in here.  RIPE NCC what are
we keeping ourselves busy with.  
              Focus for this year, some new and some not so new things on
there.  We are continuing to prepare and dealing with strong membership
growth and what we think will be a bit of a fall-off at least of a slow-down
after the v4 pool is finished up.  
              We, of course, continue ensuring and working on the accuracy
of the RIPE Registry.  We look at due diligence and fraud prevention.  I'll
talk about all this in a little while.  
              Value added through training service and major developments in
there.  Of course providing neutral information not only to our members but
and academics and the like, but to governments, regulators and the police
force as well and looking at K-root server strengthening the infrastructure
there.  
              Talking about law enforcement.  One of the previous
discussions about policy was, well, cranking up the quality of stuff that is
in the database.  
              So you'll see validation information occasionally is outdated.
 Not functioning properly.  Basically law enforcement came in said hey we'd
like you to focus on this.  There was a healthy Policy Development Process
and discussions.  
              We arrived at consensus there.  We have been asked to check
abuse contacts in the database and to follow up with resource holders to fix
outdated information.  
              Yeah, we've hired a couple of people to do this.  It's
work-intensive potentially.  Implementation started in February this year. 
What we're doing is we do some automated checks and where needed and that
will be needed we will do manual intervention contact people and make it
better.  
              Talking about training, we do training calls.  We do training
calls for a long, long time exceedingly popular, face-to-face training is
great.  Gives us feedback from our members.  We do online stuff and all the
information is freely available it's great but we don't think our members
get the most out of it.  
              What we do is we give them certificates that they attended the
training but, yeah, they are maybe dubious in benefit really because you can
come and collect your certificate and go home.  That says that you have been
there.  That's great.  
              But so we want to improve that and what we're looking at is
what we will call most likely RIPE NCC Certified Professionals and what
we'll do for that is looking, having a hard look at the identity of the
candidate, doing the exam and to have sort of basically online remote
Proctoring for this kind of thing.  
              We're in the process of setting this up.  We're dealing with a
third-party there for the proctoring.  But of course we need material
questions and the like that is useful for those things. 
              We did quite a bit of outreach to our community.  Now we're
doing extensive as I said job task analysis to get the questions right and
relevant for the task.  And, yeah, that's what we're looking forward to. 
              So the idea is like I said content will be remaining available
for everybody but the taking the proctored exam will cost money and our
members will have vouchers for that, it will be available for non-members. 
So we do this assessment platform.  We'll have people watched through their
web cams in a secure environment. 
              We might also -- we probably will also have sort of online
kiosks at our events to be used for this.  And what you get out of that then
as the successful participant is have online digital badges that you can use
that actually show that you personally did this exam and that you were
successful there.  
              So we are looking at quite some ratcheting up in our training
services.  
              RPKI remains an interesting topic.  We've seen that here
today.  We have done a couple of hack-a-thons over the last couple of years
that typically are quite popular and people come and like them.  
              So we'll do something similar with an RPKI deployathon we
brought professionals in giving talks through the whole process of validator
and playing with routers and playing with the thing and we teamed up with
Juniper in their offices in Amsterdam.  
              So that was a fairly popular event as well.  
              Talking about policies, oh, yeah, that's an interesting one, a
newish one, the BGP hijacking is a RIPE Policy Violation.  For years our
community is saying the RIPE NCC is not the routing policy.  So some people
are putting that into question and says very lively discussion about this
thing at least like three different factions talking about things, very
interesting to see.  
              Then we have a proposal reducing IPv6 allocations to a 24
after we run out of 22s that means we picked things together and give out
smaller ones from the address space that we have gained by returns and the
like.  And some other stuff basically housekeeping.  
              Yes, we're also approaching IPv4 runout.  Our membership is of
course growing.  Unprecedented growth.  We think we'll run out probably in
February next year.  Depending on undergrowth and last-minute activities
maybe a bit earlier even.  
              We'll probably have about 24,000 LIRs by the end of this year.
 It's all a bit crazy.  
              Yeah, the address pool is running out.  That's not unexpected
but it's going to happen.  Lots of transfers are happening like what we have
there, 500 per month, that's quite a bit of work.  
              And of course things are tightening up.  I'll talk about that
in a while.  
              So the last /8 is gone and we're allocating from the closures
and the like.  
              When we can't do contiguous blocks of /22s anymore then we'll
just find little bits and pieces put them together to the equivalent of /22
and give them out. 
              If you can't do that anymore then that's it.  Like I said
February 22 most likely.  Or somewhat likely. 
              So there's lots of things that we are thinking about here. 
How do we do this, transparently and efficiently but also in a way that is
fair and what precisely is fair?  
              Waiting List, do we do a Waiting List?  Don't we do a Waiting
List?  How do we do this?  Of course then we'll have to adjust our software.
 That's work that needs to go into that as well and talking about it and
keeping input from our community and how to do this.  
              So community aspects.  So should we extend the lifespan of v4
or rather not, ongoing debate for already 20 years probably.  Complexity,
working table something we're seeing, maybe not.  
              But certainly but we are seeing new kind of actors in the
Policy Development Process, basically in the community.  
              Back 20 years ago everybody was working together for the good
of the Internet and we were all very happy, all had the same goals and now
we certainly see new people coming there that have their own goals.  
              Of course also what we see and that's a good thing is
involvement of governments, law enforcement, competent authorities are here
is the word.  That look at this IPv4 thing and how we deal with this, how
the community deals with it, what the policy process, Policy Development
Process is, what form, what shape it's taking these days.  
              So it's all interesting.  For ourselves as the registry, thank
God we said early on transfers are fine, go transfer away, but keep us
informed, the registry is important.  We need to know who is using which
address space and I think that we were quite successful with that.  
              Of course, yeah, dynamics between our members and ourselves. 
We are seen occasionally as being the tough bastards that ask awkward
questions and that's something.  
              Like I said, new kinds of people are coming.  The community is
of members of the community are starting to shout at each other and are
calling each other names and not so nice.  
              We have people clearly speculators.  We have maybe hoarders. 
We do have hijackers.  We have crooks and people who show us falsified
passports and other documents to get their grubby hands on the last 22s that
abuse the system. 
              We think that system abuse is against the spirit of the
policies.  So, yeah, we have to find the right balance, be strict, be tough,
but also don't bother our good members -- our members in good standing that
just need to get the last couple of addresses for themselves for legitimate
purposes.  
              Difficult tightrope to walk.  All right.  Different topic. 
Survey.  We are doing community stakeholder membership service for a long
time.  The next one is coming up.  It will be launched in May at the next
RIPE meeting.  
              Last survey was quite successful.  We got input from 4,400
people.  But we have many, many more members.  So we tried to get more
feedback there because this is important for knowing what we should be doing
and how we could improve.  
              So that's also of course the last survey before we run out of
IPv4.  I don't know how particularly important that point is but it might
be.  What should we do afterwards?  
              We tried to keep it short.  Keep it simple.  Keep it quick so
we get more responses.  If you happen to use our services, please to respond
when that happens.  
              We use, by the way, the same people that APNIC has been using.
 There's always a bit of, say, synergy in doing this and, yeah, we're quite
happy so far with the support we were getting there.  
              Oh, yeah, we're going to Reykjavik in May.  It's soon.  You
know there will be parties without end.  And also drinks will be quite
expensive but it's all worth it because it's 30 years of RIPE community in
May, 30 years.  
              I wasn't there in the beginning.  I don't remember anything of
that.  But the community has grown a little bit from the early days.  So
you're welcome to come and celebrate and also of course work with us as
regular.  
              So if you have any questions I'll be here for the rest of the
day and during the coffee break.  
              John Curran:  Thank you.  
              (Applause.) 
              Most excellent.  Everyone should have a waitlist policy. 
You'll be tweaking it forever.  
              (Laughter.) 
              So I'll now ask the next up for reports is Kim Davies, to come
up from the PTI, and give the global report for IANA PTI.  
              Kim Davies:  Thanks, John.  My name is Kim Davies.  I head up
the IANA team.  IANA is provided by PTI, which is an affiliate of ICANN.  
              I heard it described earlier today that operations are boring.
 That's a high compliment from where I'm from.  If we can keep staying
boring that's a pretty good sign.  
              This is the team that provides the IANA services.  We
currently have 17 people on our team.  The way we operate is a lot of people
work a lot of different things a lot are probably recognized by people who
use the IANA functions. 
              I want to update you briefly on some of our customer
satisfaction work.  First is our Customer Satisfaction Survey.  Annually we
try to poll all of our customers to try to get a read on what we're doing
well, what we can improve on, and any ideas for future prioritization.  
              We segment our customers and we poll them in different ways
when it comes to number resources, our customers there are the RIRs.  We
send the annual survey to the CEOs of the five RIRs as well as registration
service managers. 
              This year the participation rate was 25 percent, which is 10
percent lower than the previous average.  That being said, we're talking
about very small numbers here so I wouldn't read too much into that. 
              Importantly to us, those that did respond were satisfied.  So
we got 100 percent satisfaction rate, which is positive.  And no one
reported any specific service issues that they wanted to highlight to us in
the previous 12 months.  
              Each customer group is asked to rank the different attributes
of how we deliver service.  And usually they're quite consistent across all
the different customer groups.  Accuracy ranking highest usually and
timeliness of our services is another priority area for us to focus on.  
              With that all being said one challenge we've had doing these
annual surveys is often the customer groups that we're polling have their
interaction with us way in the past.  A lot have been up to 12 months
earlier.  So asking them to recall how it went, what their experience was
like often results in some scratching of heads and we often get explicit
response saying we don't really remember what it's like not so much with the
RIR group but certainly with some other customer groups. 
              One thing we're transitioning into is polling or customers
directly after interaction.  That's something new for 2019.  I'll get to
that in a moment. 
              In terms of the results of the actual overall survey
90 percent of respondents reported being satisfied or very satisfied.  In
fact this year we had the highest satisfaction survey since we started the
survey six or seven years. 
              I won't dive into the specific numbers.  They're there on the
slides and you can look at themselves on your slide and they're also on our
website.  
              So we've called the tool we're using doing these surveys after
the interaction we call it how did we do.  And that's the question we're
asking common design pattern.  You've probably all seen in various different
interactions with different companies. 
              The idea is we send a simple one-question survey to our
customers and ask them a simple question:   how did we do?  Did we do well
sore is there room for improvement?  
              Optionally, once you provided a response, there's a comment
field.  If you felt there was some actionable follow-up or perhaps a
clarifying question we provide room for that but this is something new that
we now send to our customers after we finish a request.  We only poll people
once in a period I think it's currently 60 days we don't want to bombard
some of our more regular customers with constantly surveying them and
customers can easily opt out permanently if they don't wish to receive
these.  
              In terms of our SLA performance, we've hit our SLAs throughout
the last 12 months and longer.  All of our SLA performances on the website
as you heard earlier there's an annual Review Committee constituted to look
at that performance over the last 12 months and report how it's doing and
the most recent report was favorable.  
              We don't do a lot of change requests for RIRs compared to
other our areas of work.  So it's a fairly small mission.  But nonetheless
it is important and we strive to meet all the SLAs that have been agreed
with the numbering community.  
              I did want to take this opportunity to report an issue we did
have in the month of February.  It's not on the slides.  But we operate a
reverse DNS service that is used by the RIRs to publish PTI records in both
IPv6 arbitrary and IN-ADDR arbitrary only has access rights for the RIRs and
we did have an outage of that system for a couple of days in early February.
 
              The root cause of this issue was that we were migrating that
system to a new platform essentially upgrading the operating system and
moving virtual machines.  
              But one consequence of that is we restored an older snapshot
of the data that was in that system and this caused a number of knock-on
effects that once identified were restored into operation. 
              Nonetheless, this in my view doesn't meet our standards that
we strive to achieve.  So it's something that we're identifying the gaps
that led to that issue and we're seeking to correct. 
              We're in dialogue with the NRO ECG to identify anything from
the RIR perspective that they would like to see done differently in the
future.  But it is something that happened in February I wanted to share
with you. 
              One thing that's important in our operations is audits, we
have third-party audits of our assignment practices as well as our DNSSEC
operations.  
              This is one area where we feel that having a third-party come
in and analyze the way we do our operations, all of the security controls
that are in place as well as operational controls is important to give
confidence to the community about how we do our work. 
              It's in fact something that was subsequently baked into a lot
of our contracts we have with the community groups and we report on them
annually. 
              We just completed our 2018 audit cycle in the last few weeks
and I'm happy to report that our principal audit that's of interest to this
community, which is what we call the Registry Assignment and Maintenance
Systems were successfully completed with no exceptions.  
              And also additionally we do an audit of how we manage the root
zone KSK.  That was also issued with no exceptions for 2018.  
              So no rest for us.  We've already kicked off our 2019 audit
program in the last few weeks.  The framework that we used, in this case
SOC2, has added additional requirements for 2019, so-called COSO framework. 
So that's something we're working to integrate into our operations over the
next few months.  
              Something new that we're working on specifically for this
community is a new dashboard for RIR allocations.  
              The way we've done this in the past is a lot of the data that
goes into our analysis of whether an RIR is eligible for new allocation has
derived from a dashboard that was actually more of an R&D effort by another
part of ICANN and as is often the way over time, over several years, it's
come to be dependent not just by us but by RIRs as well to quickly see the
state of resources for the purposes of working out eligibility for future
IANA allocations. 
              That being said, that website was quite ancient.  It was
driven by flash, for example.  And it wasn't being adequately maintained. 
So we've gone back to the drawing Board sat down with our RIR customers to
work out what should replace it and we've come up with a new approach where
we have a dashboard that's specifically targeted to displaying RIR
eligibility for Number Resources.  This is now actively under development. 
Here are some screen shots of our internal working system.  
              It's still got some bugs and things to be sorted out but we
expect to be launching it relatively soon.  But essentially it lets you look
at IPv6 and AS number allocations, eligibility, projections towards when
specifically RIRs will be eligible and so forth.  
              One thing that's missing there is IPv4, but as you can
imagine, since we don't really have anything there to give out, we're not
planning on having an IPv4 dashboard.  
              Briefly, I've already touched on this, IPv6 we show [state] of
the RIR pools, growth of IPv6 addresses allocated in different regions. 
              What we did do is identify things that don't pertain to IANA
allocation policy, and we've stripped them out of the dashboard.  So it's
now a focus just on the task at hand.  
              And this is just a mockup.  It's not indicative of the final
result, but with do intend to show projections so that we can sort of
identify and what time window we expect RIRs to be eligible for another
allocation. 
              Speaking of allocation, our actual allocation activity for
IPv6 we made an allocation to the RIPE NCC recently.  One thing that is
notable there is that we only allocated a /22.  
              This was at their request in order to fill a gap in a larger
allocation that was made prior to the implementation of the global policy in
2006.  
              We received the specific request.  We validated with the NRO
AC that this was an appropriate application policy, and we agreed that it
was appropriate to proceed.  So that was done last month.  
              IPv4 allocation.  Well, this pretty much summarizes the
situation from the IANA perspective.  For those that aren't aware, we have a
recovered people, essentially v4 addresses that were returned to IANA and
there was a global policy for post exhaustion IPv4 allocation.  In essence,
every six months we went to our covered pool.  We divided it into 5ths and
we allocated what we had in our recovered pool to what we had in the RIR
pools.  And every allocation every six months what was in that pool shrunk
and shrunk and shrunk and gave each two each and as a consequence we only
have three /24s left since you can't practically divide that into five equal
pieces, it essentially means that this policy is exhausted.  
              Unless we get more IPv4 returned to us, there's really nothing
more for us to give according to that policy.  So that's it.  Happy to take
any questions and I'm also around throughout the rest of the day and happy
to speak to anyone.  
              John Curran:  Any questions for Kim?  
              (No response.)
              Thank you sir.  
              (Applause.) 
              So we're sitting here with a pretty substantial amount of time
before the break.  And I could just keep pulling proposals forward or we
could break.  I think we're going to break because we had the hotel set up a
little early.  So we are breaking and use the time to catch up with one
another.  
              We're going to resume promptly 3:30 here and we'll finish up
the afternoon presentations.  Thank you.  I'll see you all at 3:30.  
              (Break from 2:33 PM to PM.) . 
              
              John Curran:  If folks will come in and get seated we'll get
started.  I'd like to welcome everyone back after the break.  I see you
refreshed and energized.  Nothing like seeing a little sunshine and a little
sand and having a cup of coffee.  
              We have a few presentations and Open Microphone.  And then
we'll be done for the day.  First presentation is Bevil Wooding is going to
come up and give our Caribbean update.  Come on up, Bevil.  
              Bevil Wooding:  Good afternoon, everyone.  All right.  Today
I'm going to give an update on what we're planning to do in the Caribbean
and of course all of this will be against the backdrop of our 2018
activities where we launched the ARIN in the Caribbean series of events and
we also launched the ARIN Caribbean forum.  
              Over the past 12 months or so we have had intensified outreach
to the Caribbean territories.  We've also identified several groups that for
the first time we've been creating specific outreach to that will include
the technical community in collaboration with CaribNOG, the ARIN Caribbean
forum sector group we've been doing in coordination with several security
based agencies in the region and of course the ARIN Caribbean Public Policy
forum which we've been working with the Caribbean Telecommunications Union
to conduct.  
              As many of you have noticed all of this is happening under the
harsh conditions you see around you outside.  
              So it has been been a very intense period.  The glare from the
sun can affect your eyes.  That high-level humidity can affect the
productivity of work done in the Caribbean.  
              So I just want you to know we've been toiling on behalf of the
ARIN community to ensure that the ARIN flag continues to fly in the region. 

              So for 2019 what are we looking at essentially building on the
foundation.  Things have gone very well with the outreach structure and the
outreach strategy. 
              So the idea is to continue deepening the collaborations we've
had with parties in the Caribbean and to focus even more intently on
capacity building initiatives.  
              The reason for this is because the service we've done and the
events we've conducted have all indicated an interest in understanding more
about how to deploy number resources, how to build out networks. 
              In discussions I've had with counterparts in the ARIN
community in North America, some of these issues that have been identified
in the region are not exactly priorities for the North American network
operators.  
              But as we have gone out describing what ARIN does and as we've
gone out indicating what Number Resources can and should be used for, we've
had repeated questions about how do we learn more about deploying autonomous
networks and how do we learn more about building out v6 networks.  
              And so for 2019 we want to focus our activities on these
emerging network operators and ensuring that they're properly resourced in
fundamental topics that address those issues, IPv6 deployment, ASN, both how
to apply for it and how to appropriate it in the network.  
              On the policy side, continuing to work with the CTU and
governments in the region to look at the policies to support expansion of
networks in the region and, of course, continuing to work with law
enforcement and public safety agencies on Internet security. 
              Now, this is going to look like this.  Essentially the ARIN
Caribbean forum which was launched last year is going to be the vehicle
through which several of these outreach programs in 2019 will be conducted. 
This will involve new programs and new content being developed.  We have
started discussions with the Caribbean diplomatic community and we have had
initial conversations with judiciary and public bar representatives how to
bring greater awareness of those stakeholder groups of what ARIN is doing
and what RIRs do generally. 
              We also have had ongoing conversations with the CTU about
working even more closely with governments in the region so that governments
can be champions of appropriate and effective network utilization and number
resource utilization.  
              They have the largest networks.  They employ the greatest
number of staff and they touch the most groups of any group in the region. 
And so that outreach to governments is expected to continue as our work with
the law enforcement groups as well.  
              So what you can look for in 2019 will be more of these
community development initiatives that we started in 2018, more Public
Policy support work in conjunction with the CTU and of course more justice
sector collaborations. 
              The two channels this will be done will be the ARIN Caribbean
forum and the ARIN in the Caribbean events.  
              We're trying to ensure that we touch as many of the ARIN
territories within the Caribbean region.  For us to do that we can't fly or
visit physically every one of these territories.  So we'll be making even
greater use of virtual meetings to ensure that we at least have some kind of
touch point with the various countries in the Caribbean.  
              And a lot of that will be initiated this week as part of the
extension of this Public Policy and Members Meeting.  
              Tomorrow afternoon we'll have our second law enforcement group
meeting that will be a half day meeting with representatives from security
forces here in Barbados and from around the region, with their counterparts
from North America and also with input from our fellow RIR representatives
here in Barbados.  
              That meeting is going to be an important next step for
deepening our ties with the law enforcement and public safety community.  
              For the Public Policy group meeting, which will be held on
Thursday all day with the CTU, we'll be taking a look at some of the work
that Anne-Rachel Inne has done and she'll be describing it in the next
presentation and we'll be comparing and contrasting what's happening on the
global stage in terms of Internet policy with what the Caribbean needs to be
focusing on and what the Caribbean sees as its priorities as part of the
evolving Caribbean Internet policy discussion.  
              That takes place on Thursday.  And of course CaribNOG runs
tomorrow and runs until Friday.  And in that meeting a lot of these same
issues about emerging networks we have together with the CaribNOG team we
have identified these issues of IPv6 deployment, cloud security, et cetera,
and those have fed their way into the CaribNOG agenda as part of our ongoing
collaboration with that network operator's group. 
              So what you'll be seeing this week is essentially the first
steps in 2019 toward creating those focal points around the topics that were
identified by ARIN community members as important to them here in the
Caribbean.  
              And then coming soon, following up this week of meetings,
we'll be doing a state of the Internet dinner which John is actually
supposed to keynote.  That's part of the 30th anniversary celebration.  As
you've known we've had a long relationship with the Caribbean
Telecommunications Union that continues with their 30th anniversary plan and
the state of the Internet dinner is a chance for us to speak to high-level
officials about what's happening on the Internet, the role that ARIN is
playing and what can be done to participate in the policy and development
process.  
              Then Bahamas later in June, we'll be having an Internet week
together with ICANN and ISOC, part of our deepening of our relationship with
those organizations and their work in the Caribbean and then the Caribbean
peering forum is also in June in St. Georges Grenada, we'll be there to talk
about number resources and Internet exchange points.  
              You get a sense of what's happening how we're building out
this emerging network priority, continuing what we started last week with
network resilience and security, but also, and very importantly, finding
mechanisms for not just having events in the Caribbean but strengthening the
ARIN community in the Caribbean.  
              That's going to be a key for our focus this year.  So what
we're looking at is increasing our Caribbean participation but we also at
the same time are focusing on supporting Caribbean Internet development. 
And that's your Caribbean report.  Thank you.  
              (Applause.) Microphones are open for any questions.  Thank
you.  
              Okay.  Next up, we have the governance and -- public
governance and Public Policy update, Anne-Rachel Inne will come up and give
that.  
              Anne-Rachel Inne:  Thank you, John.  Good afternoon,
everybody.  So this is an update on some of the things that we've been doing
internationally. 
              So we're the face of ARIN outside in government engagement and
all of the international organizations that are talking about the Internet,
as you can see from this slide, this is basically what government engagement
is supposed to do, improve working relations in ARIN region and globally.  
              So when we go sit in ITU, it's funny this morning when we were
having the discussion around RPKI, it reminded me of how when John was
talking about how he can see himself talking in front of the jury having to
advocate for RPKI, I felt like this is very much like how I feel every
single time we get a question up at ITU or OECD.  
              If you do, you're doomed.  If you don't, you're doomed. 
That's really what happens every single time when we go there.  
              So we try to make sure that we keep John and the executive
team apprised of what is going on internationally so we can react also
effectively with the Board and all of you here.  
              So I'll talk about most of the meetings that you see here. 
And before I talk about PP, I'm just going to give you an anecdote that just
happened yesterday.  
              I am part of a group of folks that from time to time give
online trainings to government.  And the first week is always devoted to
telling them about the infrastructure, what is the Internet, how it works
and all of that.  
              And yesterday we had to basically go and look into a question
and respond to a clarification on what is a packet as opposed to a package. 

              You get -- yeah.  So you get a package to get connected to the
Internet from your provider, you know, your connectivity provider.  And then
you get packets, you know, when on the infrastructure.  
              But English being English, you also, when you have a package,
you receive packets.  So it was quite a little love that we had yesterday
trying to explain infrastructure on which it can get a package and packets,
both relevant.  
              It's part of the having to explain how the infrastructure
works.  So going back to ITU, international telecommunication
plenipotentiary '18, some of the most salient points for us, the
geopolitical rift state.  
              I think you all know that we are still at the point where we
have a lot of people who believe that telecommunications today should
include Internet and others who believe adamantly that it shouldn't be the
case.  
              So that rift is still there, and whenever we talk about
telecommunications, it's always hard to kind of see where do you stop in
talking about telecome and where does the Internet come and what do you
include in there or not in there.  
              So the discussion continued and we had long hours and pretty
contentious language in all of the Internet resolutions that are at ITU.  
              We ended up having minor edits in resolutions 101 on Internet
protocols 102, Internet protocols and names, domain names, 133, around
international domain names and one AT specifically about IPv6 that got a
type of change that was -- that is now called promote and deployment and
adoption of IPv6 to facilitate the transition from IPv4 to IPv6.  
              Long title to accommodate everybody and make everybody equally
unhappy.  That's what success is deemed to be in the government world.  
              So the reason why I'm telling you about the rest of the
resolutions that are here, one is an OTT is that again out there when you
talk about the Internet and mostly to regular folks, including a lot of
government people, Internet is a monolith.  They don't make a difference
between Google and ARIN.  They're all the same.  
              For them it's the Internet.  So if you say OTT, it means
somehow somewhere we're all included.  And that's the reason why we have to
be there to say no, no, hold it, this is how it works.  This is the layer
above.  This is what we do. 
              And, by the way, I was also a little -- I was smiling to
myself listening to the conversation about monetizing IPv4, if that was to
ever take place it would put us squarely into what is happening on the
discussions globally around taxation, because we would be making money.  
              So these are all things that we have to always be reading very
carefully when people say the devil is in the details, I say the devil is in
where the comma is placed.  That's how it works in government language.  
              So when we're talking about OTT, it depends on where they put
the comma or where the telecom stops, what could be deemed Internet starts. 

              And then it can be either relevant or not for us.  
              There was a possible merger two council working groups that
was proposed and finally didn't happen.  But at least we got instruction to
streamline resolutions.  
              When you go to ITU, so ARIN is a member of ITUT, the standards
sector and ITUD, the development, where they do a lot of capacity building. 

              Well, if you take IPv6, when it's the standards, in the
standards world, they're talking about how to do IoT, how to do everything
that can go through the Internet v6 tomorrow.  And in the D sector we get to
talk about capacity building, how do you get to tell people about how to
actually implement, deploy v6 and all of that.  
              And in between we end up having work streams that are lengthy
that take a lot of time, that take a lot of energy, that take a lot of
money, because believe me Geneva is not the cheapest place to have meetings
we have to constantly be there to explain no, no you can't do this.  
              Actually, if you put this type of language, you are saying you
are going to be doing policy for IP addressing.  Sorry, this is not your
job; it is ours.  We've been doing this -- this is actually the community. 
This is where people should go do it, not here, and so on and so forth. 
              Cybersecurity, you heard from APNIC and everybody, it's all
over, security is up to whom you ask today.  And artificial intelligence is
something that was very contentious because of course it involves anything
that all the talk from data privacy to name it.  
              And today we're in there because, yeah, we're part of the talk
about who is and what goes in there and all of that.  
              So Council Working Groups, just to give you an idea, we have a
Council Working Group which is called Council Working Group Internet. 
Basically international Internet public policies related to the Internet.  
              And traditionally this is a working group where the
councilmembers -- council on ITU is the body between two plenipots, between
four-year meetings basically expedite the work at ITU as the highest body.  
              So in the group that is talking about the intranet,
traditionally they have talked about anywhere from what's happened with
these policies, generic policies on the Internet to this time, for example,
one theme they wanted to talk about was IPv6.  
              But even that being like the least controversial item couldn't
get them to agree to talk about it because they came out of plenipot with
the position I was telling you and quite a few for and quite a few were
against.  
              So the full council that has been meeting in two months, in
June, will have to decide what this council working group is going to be
talking about for the next year.  
              We have the same council meeting in June.  We'll be deciding
on ITRs, so the International Telecommunications Regulations, Working Group.
 The last one couldn't agree on do we do revisions of the International
Telecommunications Regulations, of which we'll have two sets, one dating
from 1998, and I think a lot of you remember what happened when we got the
2012 ones, which is ITRs 2012, where we got the real contentious issues and
the total split in opinions. 
              So council will decide the expert working group and also
something called the expert working group for the world telecommunication
policy forum.  The world telecommunication policy forum is just a meeting
that happens exotically.  The SG calls for it.  The plenipot agrees to it
and then council decides and they've decided that it's going to take place
2020.  Plenipot is going to take place in 2020 and council will now decide
on what we are going to talk about at that policy forum.  
              Thank God it's not a policy forum that comes out with policies
that are mendactory it's multistakeholder we can put papers toward that and
we get to all participate as we actually participated in 2013 at the last
one.  
              And then we have this year the anniversary of the WSIS forum
and also we have the WSIS forum working with the UN High Level Policy Forum
at Unga the United Nations empowering people and ensuring inclusiveness and
equality.  
              Make no mistake, inclusiveness and equality may sound mundane
but it's talking about all the issues that are talked about, for example,
algorithms and issues that people are having behind algorithms, fake news
and all of this stuff.  
              This is all will be debated at the High Level Policy Forum. 
ITU-T and the work that we do there.  We participate mostly to study group
2.  Study group 20.  And we monitor very closely -- when I say we monitor
very closely, we mostly participate online.  
              So very early days for a lot of times for Einar and I because
Geneva is six hours ahead and we try and participate as much as we can in
study group 3 and 13.  13 because it's all about future networks and what
they call trusted network infrastructure as opposed to the hours that's not
trusted at the moment.  
              So you have new ideas on actually platforms that could either
work or not work with TCIP or DNS and all of that and you have quite a few
people participating in the focus groups and study group 13.  
              And participate in the TSAG which is basically in between two
plenipotentiaries TSAG is basically collates all the work that the 11 study
groups in ITU-T are doing.  
              In ITU-D just finished the work of the meetings of the study
group 1 and 2 and TDAG, too, and we got a lot out of there on IPv6 and
capacity building going forward.  
              So we'll be going to CTEL and I know Kevin is here and he
talked to you about some of the work that they're doing.  We will all be
talking to CTEL and the organization of American states where we participate
because they have a lot of capacity building initiatives on IPv6 and
networks and resiliency in general.  That has become a really big thing in
the whole region because of emergency telecommunications in general.  
              
              Some of the conferences that we will participate in or not,
actually, in 2019.  
              So GET.  Bevil was in Mauritius lately to talk about some of
the work that we've been doing in the Caribbean on helping in resiliency of
networks.  And we were not the only ones.  AFRINIC was there to talk about
some of their work they're doing with their island states.  
              And I know that APNIC has been working also with the regional
office in the Asia-Pacific on the same issue.  
              We will be participating in Global Symposium for Regulators
where the theme this year is inclusive connectivity and the future of
regulation.  
              One of the issues that we keep having is a lot of the policies
that ITU-D and DOS and regulators to put out have issues just because the
regulators themselves don't really talk to the community on the ground, do
not really know sometimes where implementing a policy can break a system so
on and so forth.  
              So we do work with them as closely as possible because they
come as much as possible to Geneva for study groups, either in T or in D and
we really try to work with them on that.  
              Radiocommunication Assemblies and radiocommunication
conferences will be in October and November of this year.  
              These are mostly spectrum.  So we don't go to those.  But we
monitor because the end product of whatever it is that comes out for these
devices that are connected afterwards anyway touches us.  
              So OAS CITEL, as I said, we work with them and we have a
working group on policies and regulations.  
              We will be putting two contributions to them that will be
around IPv6 but also some of the issues that we have seen in study group 2
and study group 20 at ITU because it is the regional work of what is going
on globally at ITU is taken down to the regions by OAS CITEL.  Some of the
issues we see with some of the governments like Canada or even the US and
Brazil and others, for example, we talk also about in there to say we've
seen this.  It will be important that you take some other factors into
account if you're doing that for the region.  
              Work on deployment of technologies and services.  Again, if
they need here training, we're there to provide that with LACNIC.  And we
have a working group on preparation of conferences where basically the
region sits and look into what is happening, what has happened, for example,
at World Telecommunication Development Conference that was at 2017 at
plenipot, what were the resolutions that were deemed important for the
region, how do we translate them on the ground and how do we collate them
into the World Telecommunications Standardization Assembly or the future
work on the International Telecommunications Regulations and so forth.  
              We go with all of the technical community.  The technical
community is actually participates in the organization for economic
cooperation and development OECD as ITAC, the Internet Technical Committee
at OECD includes ARIN, ICANN, all of the RIRs, I think, and IEEE and a few
others.  
              So we participate in the discussions, ongoing digital.  We
have participated in going digital.  The going digital project at OECD, that
has been happening for the past two years. 
              And what that entails is we just finished with a final
synthesis report.  We have a publication on measuring the digital
transformation and there's a growing digital kit.  
              In the meantime what has happened and it's going to continue
is that we have all of the OECD member countries agreeing to look into all
of their sectors at home to see what is it they have done in terms of
connectivity, policies, e-commerce, name it. 
              Everything that is digitalized today and how well they're
doing according to what is in the synthesis report that we came out with.  
              It was kind of surprising to see, for example, some of the
European countries that were the first -- one of them particularly that was
happy to play the game and be the first one to be audited, quote/unquote, by
themselves and their full community at home who were the first adopters of
v6 to completely plateau today.  
              And some of the things that we got out of that audit, national
audit that was done by themselves, was to see that even in places where you
have not only government but industry willing to go for it, there's always
roadblocks in terms of. 
              If it is cost, if it is just simply, for example, this country
is a Federation.  So they have things going a little bit like in the U.S.  
So federal, state, local, governments and all of that and people just
putting different priorities on to what they want to do, which just today
has put that country at an average level of adoption of v6.  
              So it will be interesting to see what the others come out with
in the same vein.  
              And, yeah, so another theme that we're following at OECD is
the taxation one, where you have more than 100 countries that are agreeing
to work towards consensus-based solution.  And in there I promise you
they're looking at the chain of actors in the Internet, anywhere from, yes,
the IP addresses to all the rest.  
              So if we were to be again looking to monetize IP addresses I
think we'll be looked at a little bit more closely than now.  
              United Nations.  Well, United Nations also is beginning to
talk about the Internet today.  At the third committee of United Nations
General Assembly you have major developments. 
              Two resolutions on cybersecurity were adopted last year.  One
proposed by Russia.  The other by the U.S.   And both were voted on.  Both
were adopted.  
              One has a group of experts, the UN group of experts to be
piloted by the US that is continuing.  It was something that actually has
been going on for the past at least four years.  That never really got to
have consensus and Russia has proposed the open ended working group that is
right now in the process of also being formed and we're not too sure what is
going to give. 
              Again, as I told you, cybersecurity really means anything and
everything to people.  It depends on who you ask and so we'll see what that
gives.  
              And we have a range of Internet-related rights issues.  So in
there it's about looking at the accountability processes, are we responsible
when we give an ISP a block of IP addresses and those are used to do bad
stuff. 
              Where does our accountability start and where does it stop? 
Same if you look at, for example, the issue of IP addresses monetization. 
Regional Internet registries, we manage that space.  
              So why is it that people get to sell IP addresses when we were
having the same discussion this morning when you guys have said from the
beginning that these are not to be monetized, that any of the identifiers
that are not used should come back to the global pool.  
              So these are some of the issues that we're facing every single
day in terms of accountability and all of that.  And that's why we also have
to be part of the discussion and make sure that people understand that,
yeah, well, things have evolved and maybe we just should all sit around and
talk about the future of this space together.  
              So the first committee of the UNGA has the development of
international norms also in cyberspace.  The 73rd session of the United
Nation General Assembly is significant in quite a few ways.  It has 10
resolutions that are addressing Internet issues.  Two on security, two on
sustainable development.  Two on human rights.  
              Four on human rights.  One on crime.  And you have the
cybersecurity and cybercrime that I talked about.  You have also the
geopolitical dynamics whereby, well, we're talking about things that all
should be discussed together.  
              All of us together.  What you hear more and more at UNGA is
sovereignty.  I'm sovereign; I can do what I want.  This is my jurisdiction;
I can do what I want.  
              So to be honest, at the moment, we're not too sure where this
is going to lead us, but it's out there.  
              So what happens to the multistakeholder model, really not sure
going forward.  
              Other UN organizations where talk of Internet is happening. 
We have the WTO, again, taxation.  
              What is e-commerce, what are services on Internet?  How are
they taxed?  Which ones should be taxed?  Which ones should not be?  This is
all being reflected now in the talks at WTO.  
              UNCTAD is talking about digital economy and taxation and
meeting on trade services development, helping more on the best practices
but still we absolutely need to monitor that and see what is being said,
what is being taken forward.  
              And then we have the United Nations Secretary General
high-level panel on digital cooperation that was put together last year that
will have the report soon in June. 
              We'll see what that report says and what is the view of going
forward, talking about all of this cooperation about going digital, what
does that mean, who should be there, at what level, how do we take it
forward?  
              And other activities on Internet governance.  Global Forum on
Cyber Expertise, the GFCE.  That is about awareness and understanding among
the various cyberspace communities.  
              Internet & Jurisdiction that some of you know, that talks
about jurisdiction and data, jurisdiction and content and domains and
jurisdiction.  
              There's the Microsoft Tech Accord, the Paris Call for Trust
and Security in Cyberspace, Tim Berners-Lee's Contract for the Web, Siemens'
Charter of Trust, the International Conference on Cyberlaw, Cybercrime &
Cybersecurity.  
              And they really come by the day.  So in between all of those,
we also try to look into what the ICANN is doing, mostly the GAC, and how
issues of two-letter codes and new gTLDs and country names are aggravating
governments and how they look into the technical community because we're all
together in this here.  There's a spat on IETF and https two told me you're
supposed to be figuring this out and you can't -- what do you want us to do?
 
              So there's a lot out there.  Thank you.  And I'm here for
questions now or around whenever you want.  
              John Curran:  Any questions for Anne-Rachel.  Lengthy
governance report.  
              Kevin Blumberg:  Thank you for dealing with the things that
make my head hurt.  But the one thing you mentioned during your talk was in
regards to what happens if IP addresses are monetizeed and how governments
view that monetization and the story that we've given over the years and how
we've operated.  
              I think it might be important that during staff and legal
especially for a number of proposals moving forward that that perspective be
given to the Advisory Council at a minimum and possibly something to the
community.  But I think that the Advisory Council should see the global
aspect of the things that go on in helping them weigh their decisions. 
              And I don't know if that goes on today.  It didn't when I was
on the council.  And I would suggest that that might be beneficial for
everybody.  
              Anne-Rachel Inne:  Sure. 
              John Curran:  Any other questions?  Thank you Anne-Rachel.  
              (Applause.) 
              Our final report of the day will be Richard Jimmerson giving
us the Software Development Update.  
              Richard Jimmerson:  This is a standing item that we do at each
of the Public Policy meetings typically right at the end.  It's a Software
Development Update to basically share with you how we receive our strategic
guidance inside the organization that defines what it is that we do in terms
of development inside engineering, how that work is prioritized. 
              We share some highlights since the last meeting six months ago
and talk about some upcoming initiatives that we'll be working on between
now and the next meeting.  
              Our strategic guidance that we receive is actually from the
ARIN strategic plan that's created by the ARIN Board of Trustees each year. 
              They come together around the middle of the year they create
strategic guidance for the organization and vision for the organization for
the forward two years.  
              In our current 2019-2020 strategic plan, we have a line in
there that states that ARIN is to maintain, develop and enhance
functionality of ARIN services as sought by the users and supported by the
membership.  
              And further, inside, as an organizational objective, as
defined by the Board, that we continue to review and enhance online services
including making significant user interface improvements as guided by the
user feedback customer surveys and customer suggestions.  
              As a side note, inside the hallways, inside the ARIN offices,
we actually have poster boards of the ARIN strategic plan and organizational
objectives as defined by the Board.  It's on the wall in every hallway
inside the organization.  
              John Curran requires that every January we change that poster
Board to the next version.  And anytime we're doing something inside the
organization and there's any question for a member of the staff team if it's
something that fits inside the Board's guidance we can go look at the wall. 

              And oftentimes John will invite us to do that.  We have strict
instructions inside the organization never to engage in any activity that
does not fit in one of the strategic guidance items provided by the Board
each year.  
              Factors that influence our priorities inside the organization.
 Of course, legal and regulatory.  If there's some sort of legal item that's
at issue that requires a change in our systems, that gets prioritized
immediately.  
              The same thing with regulatory items that might come down the
pike.  Ratified policies by this community.  Something that you ratify here
this week through your communications and through the Advisory Council
recommendation to the Board ratification by the Board, that fast tracks it
through our development process. 
              Also things you submit through ASPs and Board items and other
things you see here help us influence priorities in how we actually line up
the work for you.  
              Some project highlights.  Since ARIN 42, of course, you
already heard us say we've launched a new website on March 2nd but it was
much more than simply a new website.  
              Specifically in ARIN Online, everything was redesigned
basically from the bottom up and streamlined to improve the user experience.
 That was tied to some ACSPs but that was work that needed to be done aside
from the ACSPs too but we were able to close those ACSPs. 
              There used to be whenever we needed to have somebody prove to
us they were a human in one of the forms you filled out on the website you
had to fill out a math question.  We replaced it with cap cha.  And added
accessibility features for on screen readers for people with disabilities
and we've gotten some very good feedback about that since the deployment on
March 2nd, actually.  
              We've improved page display and responsiveness for mobile
devices.  We made sure the development of this product the new website the
new ARIN Online that everything works well on a small phone, on a tablet,
all the way up to a browser on a computer and we put a lot of effort into
that. 
              We implemented a combined site search/Whois search on the main
website that allows you to find things more easily and also RDAP items
related to that as part of an ACSP.  
              More project highlights since ARIN 42.  We've provided ARIN
staff with the ability to open tickets on a customer's behalf.  And the
customer can choose to either accept or reject the ticket.  
              We've had an ongoing customer service issue for years where
customers have gone down the wrong path inside ARIN Online to get something
done.  And they find out some days later and then it was upsetting to them
that they had to start all over and go through the process again because
they submitted the wrong ticket type.  
              Or they might have had a ticket that expired because it went
past the 90-day window.  Staff was unable to reopen that ticket for them. 
They had to go open a new ticket themselves. 
              There were a lot of other reasons why customers became
frustrated with the fact that we couldn't open tickets on their behalf.  So
as of March 2nd, staff is now able to do that.  
              In order for the ticket to be activated, however, the customer
themselves has to either accept the ticket we created on their behalf or
reject it.  If they reject it nothing happens within the system with the
ticket and it's simply closed.  
              We also did some Whois performance tuning.  We have -- people
are running scripts and doing all kinds of things, basically pulling Whois
data.  And we're constantly keeping up with the demand there.  And we
perform its tune Whois code so that we can keep up with that and keep a good
level of service open to everyone. 
              And we also implemented the RDAP changes described here that
we also put in the release notes for the deployment on March 2nd and that
you can also find in a blog post that engineering has done recently.  
              So going forward, some of the forthcoming initiatives.  As we
described earlier today or yesterday, we really only work on one major
project at a time inside of our engineering operation.  And then we have
some smaller and medium-sized things that we're doing at any given time. 
              The big project now that we're done with, ARIN Online and the
web rebuild, is the routing registry.  And we're working on that for the
next 18 months planned.  
              Some of the smaller-sized projects, we're going to complete
the final stage of a stateless implementation.  We deployed most of that,
actually just in this last March 2nd deployment.  In fact, we've done
several deployments over the past month since that March 2nd launch that
were transparent to all of you. 
              And at our May deployment that comes up here next month, after
that, you shouldn't expect to see any outages of ARIN Online in our services
for us to make deployments with some rare exceptions going forward.  
              We're looking to add new Point of Contact types as part of the
Routing Registry Project and some ACSPs.  We're looking at the DNS and the
routing Point of Contact types.  And we're continuing UX improvements in
ARIN Online on the website always.  We're continuing to improve those things
based on feedback.  
              You guys call us up on the phone.  One of your customers calls
us up on the phone and we get a lot of data from them.  We take and we
process that in scrums every week.  We talk about feedback every week that
we're getting from the customers, and it has an impact on the active stories
that are going into our sprints and the work that we're doing together to
improve the services for you.  So that will always continue.  
              And of course as always reduction of technical debt.  We rely
on packages and services and software to run our services to you, just like
any other company does.  And things go out of date.  Things go out of
service.  They get bugs.  They have security issues.  
              And we have to chase those down and knock those out on an
ongoing basis to ensure that our services to you can remain current and very
well delivered.  
              So with that, that is the Software Development Update, and I'm
happy to answer any questions that you have.  
              John Curran:  Microphones are open for questions.  Kevin.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. Even without my
glasses all of yesterday afternoon -- no, just kidding.  
              The new website is wonderful on my phone.  It was a constant
nuisance for us.  The only suggestion is if you could make in the agenda all
the policy proposals linked, so it cuts down driving around. 
              But it's been wonderful being able to go through things with
people using the mobile phone which is becoming the more norm and not having
to use the big, thick piece of timber. 
              Richard Jimmerson:  Excellent.  Thank you.  
              Steve Wallace:  Steve Wallace from Indiana University.  Is
there a mechanism, and if there's not, I guess this is a feature request,
for administrative POC to require all the other POCs to use multifactor
authentication for the Orgs for which that person is the administrator?  
              Richard Jimmerson:  Not systematically currently, no.  You
would have to actually talk to your POCs and require that of them but
nothing systematically requires it.  
              From what I hear, you're saying if I'm the admin Point of
Contact is there a way for me to force all other points of contact in the
organization, but really what we're talking about is the web users behind
those points of contact to use two-factor authentication to log into ARIN
Online.  
              Currently that's not something that we have as a feature, but
we'd be happy to take that as a suggestion.  
              Steve Wallace:  Thank you.  
              Richard Jimmerson:  Any other items?  
              (No response.)
              John Curran:  Thank you, Richard.  
              (Applause.) 
              Okay.  It is 4:22.  We've just got three more hours of stuff
and then we're done.  No.  Sorry.  We're actually at Open Microphone.  We
should be done in a short amount of time.
OPEN MICROPHONE 
              So let me point out we have a session called Open Microphone
at our meetings each time.  And this allows people to ask questions that
haven't come up in the presentations.  People who have new ideas ask about
topics that may not have been considered.  
              So I'm here.  We have chairs of the Board and the AC up here. 
And so the microphones are open.  Please ask away, if there's a question you
haven't had a chance to ask.  
              Steve Wallace:  This is Steve Wallace from Indiana University.
 So, yesterday I think it was you talked about thinking about creating a
program committee.  And I participated in program committees for quite a few
different events during my career. 
              And when you said that I thought, oh, yeah, that's how this is
done.  And then I thought more about it and how this meeting functions.  
              And this is my first in-person ARIN meeting so I'm a little
bit naive, probably.  I think that could be a bad idea.  And the reason is
you have few hours that are really flexible.  
              This meeting operates more like a working group with specific
tasks to accomplish.  There are people brought in to inform the folks here
who are doing those tasks in different ways to share information that's
germane to that activity.  
              And if you create a program committee and then offer
solicitation, not only -- you create a particular kind of dynamic that can
be difficult at best, you have people competing to be here, regardless of
whether that really furthers the purpose of this meeting. 
              And the program committee itself can be a little unwieldy. 
So, like I said, my first reaction is, oh, yeah, that's how you do this. 
And then my second reaction was, oh, but not this.  So I would be very
cautious about doing a solicitation. 
              John Curran:  Thank you.  Excellent feedback and food for
thought while we're weighing this.  
              Paul Andersen:  I think if anything we'd be moving very
slowly.  I don't think the intention was the entire meeting would be handed
over to a program committee, but more we would take some available slots and
experiment with that kind of solicitation and then slowly move towards -- 
              John Curran:  Do you want to respond to the -- I think his
dynamic is the fact that you have so few slots will make a contentious and
potentially not functional program committee. 
              Steve Wallace:  Yeah, you have too few slots.  And if you put
a solicitation out, you're going to create demand for those slots.  And that
creates a really challenging dynamic, even when you have large meetings with
lots of slots.  
              And it's hard for me to imagine -- I'm a newbie -- but it's
hard for me to imagine that being worth it.  
              Paul Andersen:  I appreciate that, and I apologize.  I
understand what you're saying now. 
              Kerrie Richards:  I have two comments.  One is from Jason
Schiller, Google, ASO AC.  When the Board suspended the fulfillment of the
waitlist, was the intention not just not to fulfill any waitlists or was it
to specifically put a hold on the entire Section 4.1.8.2, which kicks off an
Org, kicks an Org off the waitlist if they get a transfer?  
              This doesn't seem fair that someone who got a transfer prior
to the freeze got kicked off the waitlist, but an Org getting a transfer now
can remain on the waitlist and possibly get their waitlist request fulfilled
if they still have a need.  
              Please, please, please reinstate the text.  Any requests met
through a transfer will be considered fulfilled and removed from the Waiting
List.  End quote.  
              John Curran:  I believe -- the Board very much intended to
only suspend the issuance of resources.  So the rest of the process is
operational.  
              Now, regarding whether someone receives a transfer can receive
number resources or are they removed, they may be there now but whenever we
resume processing, they will be removed.  
              So it's addressed when you folks tell us what we're resuming. 
We will handle that as part of the transition.  There's no one who is going
to be able to get resources because their transfer happened in this window,
if that addresses Jason's question.  We'll find out.  
              Kerrie Richards:  And the second question comes from Brian
Jones, Virginia Tech.  Like the new improvements to the web pages.  Great
job.  Thank you.  
              John Curran:  Okay, thank you.  Center, front.  
              David Farmer:  David Farmer, University of Minnesota, ARIN AC.
 Could we get an update on the orphan POC and the Org situation?  And is
there anything moving forward on that?  
              John Curran:  We can get that arranged, yes.  Try to see if we
can get that arranged ASAP but it might not be this meeting.  
              David Farmer:  I guess the question is is it intended to be
moving forward?  
              John Curran:  No, it's moving forward slowly.  It's just this
whole website thing sort of is a big bang. 
              David Farmer:  There's a lot of things going on.  I can be
patient, but I just like to -- so at the table topics for the Whois cleanup,
we talked about that, so that's why I brought it up.  
              And then also in that, during that discussion, we talked
about, hey, maybe a way to maintain that going on is when a POC or Org is no
longer attached to anything, the POC or the Org -- the POC or the POCs or
the Org, in the Org case, should get notified of that, and told that their
POC or Org is going to be removed unless they otherwise -- request otherwise
or something like that. 
              John Curran:  I think that's a good topic to have when we
bring up the orphan POCs.  Rear microphone. 
              R. LeVere Harper:  Hi, R. LeVere Harper, Mondo Media.rlh and
[ISOC DB].  I just want to know, how do you go about requesting an ARIN
visit or a conference to be held in your country?  
              John Curran:  That's interesting.  So we try to alternate our
meetings throughout our service region -- Canada, US and the Caribbean. 
That generally means that we make it to the Caribbean every other year.  
              We make it to Canada every other year and we make it to the US
generally because we're following NANOG in the fall.  
              Susan -- Susan is the master of the meeting locations.  If you
find her and talk to her you can figure out when that makes sense for you.  
              Paul Andersen:  Talk to Susan.  That's the answer.  
              Krislin Goulbourne-Harry:  Hello, Krislin Goulbourne-Harry,
Fellow.  I know you all mentioned that the numbers are not supposed to be
sold.  However, they are being sold, and you are having discussions on the
what is happening, right, in terms of them being monetized.  
              But what I don't know is what possible solutions are what are
the outcomes you have been discussing?  
              John Curran:  Repeat that very last part.  I missed the last
two words.  
              Krislin Goulbourne-Harry:  I don't know what are the
solutions, the possible solutions or the outcomes that you have been
discussing?  
              John Curran:  If I understand you, you're asking what's the
solutions we have for this other than monetization.  Is that -- 
              Krislin Goulbourne-Harry:  I just want to know if you are
planning to allow the monetizations or are you planning to find a way to
stop it?  Are we going to just go with the flow and everybody do what they
want to do?  
              Paul Andersen:  So, today we have policies that allow two
parties to enter into a transaction and to transfer the addresses from one
party to another.  And that's been functioning now for, geez, I'm losing
track of time now.  
              John Curran:  Eight years. 
              Paul Andersen:  Did I say -- oh, yes.  And I guess there was a
topic earlier, though, that we're getting address space back that we are
handing out.  And that's the topic.  And how we are going to address that is
the outcome of this meeting, we hope.  So we're hoping to hear from the
Advisory Council soon and the community, of course. 
              John Curran:  We have a transfer policy that allows people who
have resources they don't use to transfer them to another party and benefit.
 
              The question is what does ARIN do with the resources that
we're taking back because someone doesn't pay their bill or they return
addresses.  For the resources that are coming into ARIN, historically we've
been reissuing them to people on a Waiting List.  
              The question is do we continue to do that, do we issue to a
subset of people, do we issue to smaller sizes?  Or do we potentially,
ourselves, bring those to market and use the proceeds for something worthy
for the community.  
              But what we do with our Waiting List resources is distinct. 
The community has the ability right now to go to market and transfer rights
in accordance with policy.  Does that help?  
              Krislin Goulbourne-Harry:  To me it seems as if it's opening
more questions rather than answers.  So it gets a little overwhelming.  
              So you have a lot of questions.  So when you're discussing,
there are a lot of questions -- what do we do here, what do we do there, you
know?  
              All the questions, but what I don't know is what do you
actually plan to do?  
              John Curran:  So the 15 members of the Advisory Council in
this room are listening to this discussion.  They're going to get together
in the next day or so.  And based on what they heard they'll refine the
proposals, all the alternatives.  
              Some of those alternatives will merge.  Some will advance. 
Yes, David.  
              David Farmer:  I just wanted to say, it's not what ARIN is
going to do, the company or the organization; it's what we, the community,
want to tell ARIN to do.  
              John doesn't decide this.  John just does what we tell him to
do.  He does a good job at doing what we tell him to do.  But even if we
think -- he does what we tell him to do even that's not what we wanted it to
be done because that's what we told him to do.  
              So it really spins back to you.  What do you want to have
happen?  
              John Curran:  Right.  You find the AC and tell them, or you go
to the Mailing List and you post what you think should happen.  And that
becomes part of the dialogue that converges on new policy.  
              The staff, we just implement that policy.  
              Kevin Blumberg:  Kevin Blumberg, The Wire. And also policies
take between 6 and 18 months, and many of these policies are three weeks
into them, so this is the start of the discussion, just from my own
experience.  
              But what I wanted to bring up was related to policy shopping
in the different RIRs.  And I want to make the community aware that I see a
concern where an author puts a Policy Proposal forward in a region and then
points to the other region and says, look, there's a Policy Proposal in that
region.  
              And the community doesn't realize that it's, A, the same
person, or, B, they decide to get a policy through in a region that's easier
for them to get it through and then they say, look, that region is doing it
and now we need to do it.  
              We need to stand up on our own and be careful with the policy
proposals that we see, that they're the right thing for our region.  That's
part of it.  
              That goes into the question about a policy, a new one.  This
morning, one of the slides said that ARIN does not require multi-homing for
AS numbers, which is not entirely true from my understanding.  
              You need to have a unique routing policy to get an AS number,
which multi-homing would be one way of doing that.  
              But there is very difficult requirements from my own
experience to be unique.  You have to have a real reason, which is not
simply just you can ask for an AS number and get it. 
              And the question is, at this point, especially with the
changes to the way cloud services require AS numbers, should we simplify and
have a policy?  And that's sort of the question for the room, that the
unique routing question or the unique routing requirement gets simplified
down to allow it to be easier to get an AS in those scenarios.  
              So from an ARIN perspective, if you could explain what unique
routing policy means, I think that might help inform the community as well. 
              John Curran:  Certainly if the community wants us to simplify
the AS number issuance policies, then that's something you should tell us
clearly.  And it is possible that the world's changed such that that makes
sense.  
              This man's name is Kevin.  Converge on him and talk about a
Draft Policy if that's what you want.  Yes, you want to comment on that in
particular?  
              Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  I'll
point out that there's quite a long history of policy proposals that do
nothing more than but codify and clarify what is currently the standard
operating practice among ARIN staff.  
              And someone just says, hey, we're doing this already, but this
could be ambiguous.  Let's actually write a policy that makes it in black
and white so everybody understands what it is.  And that's perfectly
acceptable.  
              And that's, in this case, that's probably something -- that's
probably absolutely what I'd encourage.  
              John Curran:  Center front mic.  
              Suzette Burley:  Suzette Burley, an ARIN Fellow and also
representing Digicel Jamaica.  I know first early on -- this is not my
question, by the way -- but we spoke about what we do with the funds from
auctioning those IP addresses that was returned. 
              I have a suggestion.  We can use it to continue with the
fellowship program and inviting more persons to come as fellows.  So that's
my suggestion what we can do with it.  Since we haven't quite decided on
that yet.  
              But my question is, from my interaction with different IP
engineers, especially within Jamaica, I found out that a lot of persons did
not implement their IPv6 Internet infrastructure because they did not know
how to.  
              And this was a general concern as I was going around having
different conversations.  So my question is, do we have an online webinar,
because not everybody has the resources to visit the conferences?  And if
so, how is that advertised to the POCs?  
              John Curran:  We're in the process right now of spinning up
training at ARIN.  And we'll talk a little bit about that tomorrow in our
community, in our department reports.  And v6 is one of our first focuses.  
              Rear microphone. 
              Richard Wahl:  Richard Wahl, ArkiTechs.  My question is
connected to the training, so you answered it already.  Could you give us
insight into what are some of the programs that might be offered on these
trainings?  
              John Curran:  I believe we'll have that discussion tomorrow. 
Susan will mention the training at ARIN initiative underway.  
              Owen.  
              Owen DeLong:  Owen DeLong, ARIN AC.  Going back to Kevin's
comment about AS numbers and requirements from cloud providers, as I
understand it the times when cloud providers are requiring you to have an
ASN are when you're announcing routes to them for subsequent distribution to
other providers.  
              If you're announcing routes to a cloud provider that they're
now announcing to other providers, that is indeed the very definition of
unique routing policy and therefore would qualify you under current policy. 

              John Curran:  Kevin is this guy over here.  You should get
together with him and talk to him about it.  Next over here.  
              Rudi Daniel:  Rudi Daniel, I'm a fellow and also speaking for
myself and [(indiscernible)] in Saint Lucia.  Just a comment really.  I
would hate to see ARIN going into auctions and the other reason is that once
we have the money then we have to decide what we're going to do with the
money, and that's going to be very contentious issue anyway.  So I would
hate to see that totally.  
              I also wanted to ask, do we at ARIN actually monitor the
commercial market for v4 addresses currently?  
              Also because some of the proposals we have here, we need to
know what the market is like on the outside in order to determine what we're
going to do.  We also want to know the value in relation to block size, too.

              John Curran:  So, you asked the question, do we monitor that
market.  I'm going to say yes and no.  Yes, we monitor the transfer market
to make sure that there's a healthy rate of transfers going on to have an
early heads up in case something goes wrong somewhere and for some reason
the transfers aren't working at all.  
              But that's literally just making sure John's graphs of
transfers are increasing and we see them going within the region and
inter-RIR.  The number you're thinking about is do we look at price
associated with them. 
              The two aspects of that is, one, we don't ask for that.  In
fact, we work hard not to ask for that.  So we don't monitor that.  But
there are a number of people who publish full-on reports about the health of
that market:  Number of transactions; where they're going; average prices
involved.  
              So if the community gets to the point where it starts talking
about monetization of these numbers and -- we can provide them numbers.  We
don't need to monitor the market.  
              We do have this public, easily obtained public sources about
the size of that market. 
              I'm closing the microphones.  Go ahead.  Last one.  Remote
people, closing.  Go ahead.  
              Chris Woodfield:  Just one more point.  There are members of
the AC and I believe now of the ARIN Board, I'm sorry, the ARIN Board, that
are part of the reseller market and do have insights that other members of
the community may not.  And that insight can be used to shape policy. 
              John Curran:  Right.  If you raise your hand and say, I'm
looking to buy IP addresses, they'll find you.  
              So any other questions?  No?  Last Call.  Final call.  Okay,
I'm closing the mics for Open Mic and that ends the last session of the day.
 
              Let me do quick announcements.  
              I'd like to thank our sponsors, C&W Business and Google. 
              (Applause.) 
              And our event sponsors, platinum sponsor Addrex; silver
sponsor, IPv4Mall.  
              (Applause.) 
              Okay.  We have a meeting survey.  The meetings, we improve
them based on your feedback.  Please fill out the survey.  We're actually
going to enter one of you into a drawing -- we'll enter all in the drawing,
but only one of you are going to win to get an Xbox.  
              Reminders, we start tomorrow at 8 AM.  Our Public Policy and
Members Meeting starts at 9.  Thank you everyone.  Enjoy your time at the
beach.  See you tomorrow at 8 or 9.00 a.m.  Thank you.  
(Meeting recessed at 4:45 p.m.)