[arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes
Matthew Petach
mpetach at netflight.com
Thu Oct 22 17:03:50 EDT 2009
Wow. that was quite a bunch of discussion today. ^_^;
This is long, and there's a few gaps where I couldn't keep
up with people, but hopefully this captures most of the
debates that went back and forth.
Thanks!!
Matt
2009.10.22 ARIN 24 notes, day 2, part 2
We return from lunch at 1330 hours Eastern
time when John starts things off.
We start off with presentation from Andy Newton
talking about the RESTful WHOIS service.
Whois-RWS
Representational State Transfer
defines a pattern of usage with HTTP to create,
read, update, and delete (CRUD) data
"resources" are addressable in URLs
very popular protocol model
amazon S3, Yahoo, Google services, twitter clients...
Why now?
major refactoring needed for current WHOIS services
to support DNSSEC
implementation of new system just as much work as
fixing old ones.
reused ARIN Online components
Higher utility than just NICNAME/WHOIS
POC, ORG, NET, ASN resources have URLs that you can
cut and paste
gives simple programmatic API into whois data
compared to NICNAME TCP/43
better inputs and queries
more meaningful outputs
builds on HTTP parsing
RESTful web services
O'Reilly, Sam Ruby, Leonard Richardson
http://whoisrws-demo.arin.net/
demo available now
currently have RESTful web service,
database for server cluster, sync'd to
registration database.
NICNAME/WHOIS port 43 proxy now feeds
data to RESTful service.
Web From interface is what you see on the page, it
emulates the text box on main page, it uses XML
with XSLT style sheet to transform it
You already have clients
it's called a browser.
You can use command line clients to retrieve info as well.
Modern web browsers do XSL transforms
stylesheet not yet inserted into the XML
needs software upgrade
Firefox will show formatted XML
that part is usable today
all browsers can use the web form.
Command line clients:
found on unix and cygwin
curl -- robust HTTP client
wget -- robust HTTP client
xmllint -- XML tool supporting HTTP
xsltproc -- XSL transformer supporting HTTP
Offer port 43 proxy
use host option with favorite client:
whois -h whoisrws-demo.arin.net blah
Demo of request:
/rest/poc/KOSTE-ARIN
Addressable URLs
http://whoisrws-demo.arin.net/rest/poc/KOSTE-ARIN
/rest/org/ARIN/asns
/rest/org/ARIN/pocs
Searches:
same capabilities as port 43, but can be refined
Matrix URLS
/rest/orgs/;name=ARIN
/rest/orgs/;name=ARIN*
/rest/orgs/;first=Mark;last=Kosters
IP Addresses
/rest/ip/v4/192.149.252.254
/rest/cidr/v4/192.149.252.0/24
relative CIDR
/rest/cidr/v4/192.149.252.0/24/less
Outputs
XML
JSON
very popular for AJAX web2.0 type sites, popular for clients
for mobile phones. Originates with javascript.
with stylesheets, you can transform the output to your needs
we provide some XSL stylesheets for translation to make
XML look like traditional whois
demonstration of xsltproc using xsl template (detail-template.xsl)
Future enabled: caching
addressable URLs make HTTP caching work with WHOIS data
useful for automated security analysis
91% of Whois queries are IP address lookups
Security analyzer<->local web proxy<->RESTful Web Service
Future enabled: referrals
rwhois referrals to downstream RESTful services
Future enabled: Auth*
Authentication allows tiered authorization
policies no longer need to assume all or nothing.
Versioning:
with standard HTTP headers we can version the output
change data model with as little disruption as possible
Always gets the latest if you don't specify
Accept: application/arin.whoisrws-v1+xml
Documentation on website
http://whoisrws-demo.arin.net/docs/whoisrws-api.pdf
mailing list, arin-rwhiosrws
Frequency of updates
featuring 'near realtime' updates
data replicated from registration database every 10 minutes
made possible by re-using components developed for ARIN online
Feedback.
Rob Seastrom, Affilias, this is good, and really cool; he
focuses on cacheability of this. It's not just the
addressable URL, it's max-age, and cacheable; does it
support If-Modified-Since?
A: that can get complicated quickly; they punted and
didn't do anything. You can assign your own local policy
on that. They run mod_memcache and mod_poxy, and set their
own policies on how long data gets cached.
In his opinion, people should think about local policy
first.
Owen DeLong, HE.net, lots of talk on the channel looking
for text output instead of just PDF and DOC.
There are a lot of tools that depend on port 43 output;
CIDR queries on RESTful good; lack of CIDR on port 43, bad.
A: They run confluence internally, it spits out doc and pdf;
it's hard to find a format that appeals to many people, but
they'll try.
And they're not going to get rid of WHOIS on port 43
any time soon.
The current service doesn't provide CIDR lookup support,
because the parsing on port 43 is non-trivial.
The query actually hits many different elements on
port 43, which makes the parsing hard.
Ted Middlestat, internet partners, -- the policy only
allows ISPs to run rwhois as permittable alternative
to SWIP at the moment; NPRM needs to be updated to
allow RESTful interface as alternative to SWIP or
RWHOIS before ISPs move in this direction.
David Williamson, TellMe--finding one output format
for everyone is tough; don't find one, provide many
formats is good!!
XML and JSON were chosen, the stack supports them out
of the box.
TEXT is actually harder to do, more formatting rules
Steve, MIT, thanks for CIDR blocks; will this be rate
limited at all, and will it be rate limited different
for good guys vs bad?
A: No rate limits now; limited result set size.
Will look at where it's appropriate, and what
size responses are appropriate.
This is a pilot service; it will at times go
down. This is for community to evaluate. If you
need production level service for this, let them
know.
Leo Bicknell, ISC -- does this support :: notation
for IPv6, or do we have to fully specify?
A: Not sure, test it and let him know. ^_^;
Thanks to Andy!!
Draft policy 2009-8: equitable IPv4 run-out
June 8th, 2009, draft policy 2009 aug 31
similar policies in all regions.
Slows distribution of IPv4 space
Changes policy for ISPs who have been ARIN members
for more than 1 year, decreases from 12 month
supply to 6 month supply at 20 /8s in ARIN free pool
When IANA hits 10 /8s, largest request is 1/4 of free
pool, once every 3 months.
Legal risk--the rules must make clear, rational sense,
and must be checked for side effects that would favour
one ISP over another.
max prefix size may not be available as a single
allocation by the time the request is granted.
4 posts, 2 people, none in favour, none against.
will minimum allocation shrink? If they get a /22
every 12 months, what do they get at 6 months or
3 months?
Goals:
ensure an equitable distribution of the remaining
v4 addresses
ensure multiple organizations have an opportunity
to receive IPv4 resources
Reduce the disparity of IPv4 resource availablity
between competitive entities
Goals
demonstrate due diligence when ARIN is called to task by
the courts
the politicians
the press
the public in general
Reduce chance that IPv4 run-out leads to
instability of the internet
Avoid a friday night massacre of the ARIN free pool
someone cleans out ARIN with a LARGE request
late on a friday
everyone gets big surprise Monday morning
NOT intended to extend life of IPv4 resources
you just request smaller bits more frequently
Reduces length of supply from 12 months to 6 months
then 3 months
Creates a maximum allocation size from last /8 of
1/4 of the available ARIN free pool
thus, maximum allocation size will decrease over time,
accelerating towards the end
The current text may have the trigger too soon
will definitely cause some additional deaggregation
may cause some extra work for larger consumers and ARIN,
as they come back more often
Trigger adjustment
looking at the run-out projections, may be able to trigger
later than expected
possible change first half to IANA down to 10 /8s, reduce
to 6 month,
don't drop to 3 month supply until ARIN at last /8
Why is first part triggered on IANA pool, when ARIN isn't
biggest drain on IANA pool?
Editorial note:
change 4.2.4.4 from twelve months to subscriber members
after one year
change 4.2.4.3 three months to subscriber members less than
one year
Floor is now open for questions/comments.
Martin Hannigan, Akamai, wildly objects. Distribution method
needs to be fixed. Smaller will get 100% fulfillment, larger
will not get fulfillment.
Need to incorporate percentages, not fixed allocation size.
Igor, Yahoo--how does this affect the transfer policy; it does
not affect the transfer policy. Both exempt each other, so
this will not affect justification for transfers or how
frequently you request transfers or from these pools.
Stacy rejects this policy, and any other policy that
stretches the party out.
A: but this isn't stretching the party out; this is setting
down rules of equity as we get to the last five minutes of
the party. We're not trying to conserve resources, we're
splitting up the last six pack!
Stacy thinks if a large ISP can justify the last /8, they
should get it.
someone else at mic -- having seen the issues at other RIRs,
congratulations on cleaving the baby cleanly!
Trying to avoid bad hurts at the bitter end is good.
The second half is reasonable when the space is completely
under your control. Cutting back the earlier half to
a later date is good. The early slowing may provoke the
same concerns that were just heard unnecessarily. He
would support it as is, but would prefer the last part only
about 1/4 as biggest when there's one /8 left.
A: Leo notes that the place from which they started
approaching it was the case that if there was no wind-down,
there would be ISPs who get address space on last day, edging
out the guy who was in a meeting that day.
The 12 month delay was to minimize that disparity, and to
give people more time to be pickier about what they give
out to bigger customers.
Trying to find the least intrusive policy window to allow
ISPs to get a 12 month advantage by sniping at the last
minute.
Also, when last /8 is allocated to ARIN, /10 is reserved,
so only 3 /10 ISPs could be given out anyhow.
Rob Seastrom, the cour of public appeals--this will be
perceived in the press as having been done to lessen the
impact of runout, or that it somehow preserves IPv4, and
it softens our message that the future is in IPv6. It's
not clear that any level of change to the policy will
affect that perception.
John notes ARIN retains a PR firm which is used occasionally.
For something like this, they could do briefings ahead of
time, and prepare the right answer for people who may be
reporting on this to help get the right message out.
Mark Wilson, uncommon technology -- he opposes the policy as
written. The final trigger, the last allocation; instead
of waiting for random emails, why not take poker approach;
look at the last year's requests, and divide up the pool
based on the percentage of the previous year.
Second comment; after the IPs run out, we'll see some
industry consolidation take place, esp. at smaller
end of the marketplace.
Chris Morrow--has concerns about the wording; it's not
about equity, it's about need. There's always going
to be someone who comes in after the last block, someone
will always lose.
A: the wall is coming. someone will eventually lose.
We just don't want to hit the wall at supersonic speed.
Ted Middlestat--in favour of policy, though he doesn't
think policy will help; orgs who are smart will move
to IPv6. The stupid ones will be gaming the system
anyhow, and generating bogus needs. Orgs that need a /17
will generate requests for /15s instead. The Friday
night party will be all the procrastinators who haven't
prepared, and will be out of business 6 months later.
So, this is harmless anyhow.
Matt, Affilias, he's in agreement with being against
the policy. The due diligence is getting people to
move on, not soften the landing. This policy will
give the impression of wanting IPv4 to last longer.
But the minimum allocation size doesn't shrink.
Text needs to be explicit about that.
Scott Liebrand supports the proposal; he feels that
the concern that we shouldn't look like we're fixing
things is not what we should do. We are in a situation
where what we're doing is trying to head off percieved
unfairness. This won't be just about need, because
there will be *more* need than supply; when there's
more need than supply, we don't have a defined behaviour.
If we don't define it, others (gov't) will do it for us.
Joe Maimon supports the policy; if one or a few big
players clear out the final supply, we can end up with
a prime time sound bite. ARIN should aim to prevent
gaming.
Cathy, what if the wall moves? What if we hit it,
and then a big block is given back? None of these
policies address that.
A: If ARIN gets a sufficently large enough block to
move the 1/4 maximum allocation size, that's all that
really happens; it still holds.
Chris Grundeman, supports the policy. To the competitor
getting a bigger percentage, that's why this is time
based; you get 100% of your six month need, so is everyone
else. Only when there isn't enough left for your six month
need, do you get less than your full need, down to three
months. But really, the big ISPs need to be looking now
to move to IPv6, not when the runout happens. The addresses
will get used up just as fast no matter which model we use,
this just divides them a bit more fairly, and allows new
ISPS to play.
Robert Duncan, Merit--this is more of a CYA for ARIN; anyone
smart is already planning ahead; just the procrastinators
who are terminally stupid will get into this.
Fishing industry has precedents for controlling limited,
dwindling resource.
This has to interact with 2009-3; what happens with the
address space that comes back needs to be explicitly
stated. But he supports it.
mics are closing
Alex Kostella, could a show of hands be made for support
of policy with adjusted triggers.
A: understood
Leo, ISC, if you have comments on triggers, please comment
on 10 /8s and last /8 as trigger points.
Also, earlier comment about an ISP who received resources
late in the game would become an acquisition for a less
fortunate company. Is it really a bad thing? Can there
be clarity or explanation around that? How is allowing
someone to be an acquisition target for their IPs is
a good thing?
Mark says it'll happen, it's neither a good thing nor a
bad thing. Normally in startup mode, one of the easiest
ways to grow bottom line is to buy up competitors. You'll
see consolidation, the small garage operations will get
slammed together to get critical mass.
Intent here is that this will happen, it always happens,
it always will happen. We want to avoid the runout from
causing a hugely artificial surge in them, to the point
of causing market disruption.
A: this reduces chance of someone being in that position
*solely* by being last one through the door.
Ted Mittlestat, internet partner--if wall moves, it must
be understood that when IPv6 is in gear, there will be
spare IPv4 being returned. IPv4 will never likely go
all the way, but it will just go to maintenance mode.
Joe Maimon, show of hands for doign nothing?
someone from ATT, opposed based on perception of this;
if we put together policy, we're almost sending message
that we're extending the life of IPv4 until we don't
know when. If Geoff's prediction say 2012 now, will
they extend out to 2013 due to the smaller pools being
left. Right now, ATT is pushing for IPv6 rollout, but
the beancounters want to delay the deployment as much
as possible; they want to send the message that they
have to do IPv6 conversion as fast as possible.
A: There's a perception problem, yes, but the perception
will be worse if it looks like we did nothing at all to
prepare. Right now, the policy says that if you're a
big consumer, you can take that last big chunk on your own.
Scott, Internap -- Leo's question, should thresholds change?
First threshold takes us back 6 months; everyone else changed
it, we can go back to where it was earlier, but it shouldn't
be a reason to oppose it.
If there's people at the party, they're not just the idiots;
they'll be dual stack, they'll have v6 customers, but they'll
still need v4 to talk to the rest of the internet still.
So, the question is really do you get 'free' addresses vs
having to pay for them.
Chris Grundemann, the 20 and 10 /8's seem to be about 2 and 1
year trigger points based on current burn rates.
Is the concern about the *perception* of extending v4, or
does anyone actually think this will really extend to the
real runout? Because it won't extend it at all.
Martin Hannigan; it won't do anything for extending it, it
may just create unfair distributions. If he wants to
battle people, he just wants it to be fair at the end.
Scott; if someone goes to the well, and there's not enough
for them, that by definition is runout. It means some
can dither longer, but they will have run out at that date.
Owen DeLong, HE.net; this policy goes from a situation
where one large request empties the well, to one where
many smaller requests empties the well. It's not clear
which one is "fairer" -- one big drink, or many small sips.
It won't exend the life.
Matt, Affilias--this changes from one big request can blow
away, to one big request just gets a part. It doesn't
extend significantly at all. It's just a perception issue.
Trigger conditions:
For those who will vote yes only with existing trigger,
or only with modified trigger; if you're so sensitive to
trigger you can only be in favour of one trigger or the
other, or you won't support, go to a mic now.
one at mic; he's opposed to current trigger. He thinks
that two steps seems like trying to slow the train; he
wants just one step, otherwise he'll support.
Dave Barber, he's against the proposal; but if he takes
second bullet alone, and moves to a single step, to a
six month cycle. He would be in favour with just that
trigger adjustment.
Matt affilias--might support it if just the triggers
were there; if we remove the "quarter of the supply",
and let everyone get 100%. But if we just change
the trigger, he'd still oppose.
Martin Hannigan opposes the policy regardless of
trigger.
Is there anyone who will only vote for it with the
original trigger conditions? Nope. yay.
OK, the 1/4 limit in the final /8, is that needlessly
complex or wrong; if you are against the 1/4 limit,
approach the mics.
Dan Alexander--in regards to triggers in general,
there's a sense we have to do something to show to
try to soften the wall. But what if we all decide
to just hit the wall?
Dave Barber, ATT--we're getting too granular at that
point. If we cut back to a six month allocation at
that point, then 3 months, and 25%, that's where the
perception will look like we're going to rationing
to try to extend this.
Owen DeLong speaks against 25% limit; it just selects
who fights over the last crumb. The downside to it
being there increases the number of prefixes handed
out without providing benefit to the community.
John, it's not about anyone who gets address blocks
at runout; it's the org who shows up just afterwards;
their anger will be smaller if we haven't set up a
'winner take all' model for the final allocation.
That will reduce the threat to this community.
Chris Grundemann, he likes it, because the last /8 is
the dregs; with this, it sets the perception that you
can't get lucky and get a big allocation at the end.
if you can only get 25%, it helps push big ISPs to
move *sooner* rather than later, since they're less
likely to fit into the space.
Support of proposal with triggers AS reduced according
to the alternate slide:
trigger conditions set to IANA pool at 10 /8s for 6
month supply, and
ARIN supply at last /8 to move to 3 month supply.
This is the SOLE vote for adoption; there will be some
discussion about 25% later. If you vote NO, you reject
the entire policy! The other changes on next slide will
be left to AC to consider.
For 2009-8:
in favour: 30
opposed: 28
total voting, in room, and online: 136
AC has a complicated job with this one...one more show of
hands.
Assuming the policy gets adopted due to stellar support.
Would they like to have the 25% or no limit?
YES in favour of 25% in last /8, or NO to 25% limit in last /8.
in favour: 26
against: 33
total voters, in room and online: 137
How about asking how many would support it with the change
he just proposed? No, too many combinatorics.
BREAK time!
19 minutes, get moving!
Be here at 1530!
OK, back after break
Policy Experience Report
Leslie Nobile
PDP cycle slide shows where in the formal process this
lies;
after the implement phase before the next need phase is
this evaluate phase.
Review existing policies
look at existing policies
abiguous text, inconsistencies, gaps
identify areas where new policies or modifications may be needed
operational experience
customer feedback
provide feedback to community
make recommendations
Policies reviewed
identify invalid whois POC 2008-7
not fully implemented, some issues to bring to community
and get feedback
M&A transfers (NRPM 8.2)
On 2008-7
sentence about email sent to "every POC in the whois database"
Sprint cleaning/trial run
emailed all registered POCs with direct resources
contacted 42,920 POCs, asked to update records.
Staggered emails; 4 months to complete
4% response rate.
POCs with reassignments left to contact, about 359,000!
It will take 33 months to contact the 359,000 with
staggered emails to avoid getting slammed by responses
and calls.
ARIN has no direct relationship or contract with
downstream POCs
upstream is responsible for entering reassignment
information; could cause confusion on part of the
downstream.
RSA 5.b says the org must maintain and update data
put in for their customers as well as their own.
Would like to *only* send to all direct allocation
POCs; make upstream responsible for their POCs and
their downstream.
Q:?
Owen Delong, he.net; it is important to spot check
that ISPs are maintaining the information, to do
the due diligence on reclaimed blocks. While a 33
month project every 12 months is untenable, can we
select 10% of the downstream POCs and change the
policy language to support this?
Chris Grundemann; for the 43k POCs contacted, did
email request *all* respond, or only respond if
there were changes. The 4% was scary if they were
*all* supposed to respond.
The original intent was to automate the process, so
that automated email goes out, with a link to click
to validate the person is still alive. Wouldn't
that vastly reduce the amount of time needed for
this?
A: yes, would be automated via ARIN Online.
But the 359K don't know who ARIN is, and don't have
a relationship with ARIN.
Opposal to the 10% part; goal was to have this done
*before* the free pool runout.
This is just updating the POC information.
But he meant that address space with no valid POCs
could be investigated for reclaim.
Ted Middlestat, he was well aware that downstream
POCs would not respond; didn't intend for this to
aim at those.
Joe Maimon, why don't these logistics warrant emergency
action.
someone at mic; you're only supposed to be able to
update POC if you're that person. Can ISP just update
the POC records for customers, even if not listed.
Nate Davis, ARIN, can they talk about phone level support
needed for these.
They got hundreds of phone calls from this effort.
Leo Bicknell, ISC -- one question, one suggestion.
Did they look at volume of POC changes coming in,
rather than replies.
The POC updates was the 4% number, and 12% bounceback
rate as undeliverable.
All POCs got sent same email, which led to one updating
about others no longer existing.
If ARIN sends to downstream POCs, the correct thing is
to say to to contact upstream POC, not to call ARIN;
the upstream may not be happy with that increase in
NOC support, but they did promise to handle that.
Ted Middlestat, none of the staff working this have
contacted the authors about modifying it; please
contact them outside the meeting for suggestions.
A: Once a policy comes into existence, it belongs to
the community, not the authors.
Andrew Dul, does not agree to sending email to the
downstreams. Intrigued by sending from the upstream,
or directing them to the upstream.
How do you verify the people who come back are the
ones authorized to make the changes if you go to
downstream; you don't have a business relationship
with the downstream.
Focus the efforts on the direct allocations; worry
about the other parts later; not what the authors
intended.
Heather Schiller, Verizon, giving feedback, as one
of co-authors; she disagrees with Ted, and feels
coming to community is right. They got a bunch
of emails from ARIN, went to all the POCs, with
a link to each POC; they weren't as on top of their
records as they thought; there were people listed
as POCs from other companies, couldn't even untangle
how it happened, and was glad she got the mail first
before they asked to have her removed from the records.
It may create additional burden, but please take it
seriously; you could get removed from your own resources!
Those with BGP validation may not worry, but the rest of
us need to worry.
When the email comes out, it's a race condition.
Chris Grundemann--whois authorization between POCs
is separate from these.
Other main concern of this is to have abuse contacts
is useful, rather than just main contacts.
Owen Delong, ISC -- ARIN has a contract with upstream,
there is a transitive clause in it; it's not certain
it'll prevent it from being blocked.
Ted; if you don't support sending email to the downstream,
raise policy to change NRPM.
Joe Maimon, if you don't agree with this, emergency policy
action may be needed.
M&A transfers (NRPM 8.2)
this says that the assets being transferred must have been
used by the entity at the time of the acquisition.
Issues:
text could be made clearer
transfer requests often come years later; hard to know what
was in use at the time of the M&A
should utilization at the time of transfer request be
considered?
if there's little or no utilization, should future use count?
The more stringent the requirement, the more likely the transfers
are to be abandonded and the ARIN data inaccurate
currently 60-75% of transfers get abandonded
Currently, requirement is to know how the resources were
being used at the time of the acquisition. If there's
usage 2 years later when the paperwork is submitted, should
they be penalized? And if they have a plan at the time of
paperwork submission, should that be allowed?
Current practice:
focus is on completing transfer and getting accurate info
into whois
typically if transfers have proper documentation, but resources
are under-utilized, they will request return, but will approve
the request.
Recommendations
liberalize the utilization requirements by allowing any of:
resources in use at time of acquisition
or in use at time of transfer forms
or demonstrate they will be utilized within 12 months
Leo Bicknell -- ISC -- doesn't like the OR. They could be
in use at time of M&A and then abandonded, which isn't
quite right.
Actual problem is that ARIN needs to find a way to make
sure that M&A transfers happen closer to actual event.
What if ARIN got a check for payment of fees with a
new name, can they flag a start of transfer process
much closer to the time event?
A: it can be hard to unravel the person paying the check
from the company acquisitions involved.
Q: you don't want to let someone get away for long periods
of time without updating information. How about a penalty
financially for not updating M&A information?
But often there's no payment coming in for these, often;
not getting charged fees.
Owen DeLong, he.net; there should be payment coming in
for the year assets were transferred seems a worthwhile
endeavour. You can't transfer legacy without signing
RSA and paying fees. So at time of transfer, they should
have started paying money. But they don't accrue back.
Present operational practice is not to accrue back.
But at the moment, the policy is to charge from the point
of the transfer.
We should make policy clearer.
The issue in this is that there is legacy space, and it
goes off into ether for years, and then someone realizes
that transfers can be used for hijacking space.
The problem isn't really solved, the address space is
still there if the transfer is aborted.
There's nothing preventing ARIN from reclaiming space
from aborted transfers, because they're no longer the
holder of record for it anymore. :)
He does not like the ORs at all.
Tom Watkins, Intellus -- he acquired IP space in past
with acquisition; he still pays bill from old company
name, it was probably never transferred because it
was too much of a hassle. He's current on payment
for both, but they go back 8 or 9 years, so the OR
really are importnat.
Ted Middlestat, current utilization policies are fine,
but do not let them keep stale records out there!
Scott Liebrand, volunteered to help rewrite it, wants
lots of input from people.
Now that IPv4 transfers are easy, and don't require
M&A documentation, is this easier.
Most have ASNS as well which still need this.
Next up, AC has many policy proposals on the docket;
AC on-docket proposals
John Sweeting, advisory council chair
Proposals
4 on docket, not yet ready for presentation, prior to open
mic period runs through them
proposals added to docket or abandonded; if on docket,
goes to AC and PPM for discussion
Proposal 95: customer confidentiality
Proposal 97: waiting list for unmet IPv4 requests
proposal 98: last minute assistance for small ISPs
proposal 99: /24 minimum allocation
PP95: only require names for customers, ISP can provide
their address and phone number; but if ARIN requests it
ISP must provide it to ARIN.
Aaron Wendell
PP97--waiting list for unmet IPv4 requests; would
require a single contiguous allocation be granted
for each request, and create waiting list by stopping
people from getting smaller blocks.
pp98--last minute assistance for small ISPs, reduce
ISP min alloc size from /20 to /23 as the last /8
runs out
applies only to last /8, not transfers
pp99, owen delong, multihomed end user minimum
lowered to /24; getting larger block requires
renumbering and giving smaller block back.
Your feedback appreciated, lunch conversations
were really good.
AC to work these with clear goal of developing
these into clear policy drafts.
Back on schedule. Allowed 1 hour, we have 43 minutes,
that should be plenty!
Any suggestions, operations.
Bill Darte, Wash U, at this meeting and past meetings,
we had lunch conversations; we used that time in part
to look at these proposals on the dockets; thanks to
those at their table, it has been greatly appreciated
as they go into deliberation on it.
Stan Barber, director of texas IPv6 task force.
Appreciation to ARIN for sponsoring initial activity
Nov 3 and 4th in Houston, ARIN is gold sponsor, check
out the website for more, www.txv6tf.org
Ted Middlestat--show of hands on how many want to
soften supersonic crash, and how many want to do
nothing?
Owen--canyon flying, point of no return; canyon is
narrow enough you can't turn around, and walls are
high enough you can't climb out.
Scott liebrand--alternate is a subsonic crash!
Ted wants to know if we should work on this,
or abandon David's efforts.
Chris Grundemann, doesn't like metaphor of
crash; IPv4 doesn't stop working, we just
can't grow that portion of internet; we can
coast to the nearest gas station, or just
stop.
Kevin Oberman, es.net; this will be a crash,
as many companies go belly up, as their business
plan turns out to be worthless. There will be
a crash, it will be bloody.
33 for crash
27 against the crash
Jason Schiller -- verizon -- in favour of crash.
We've always had need based policy here; it seems
to be a fair approach. Why is what we're moving
to "more fair" close to the finish line?
Rationing is it increases pain point because they
cannot get addresses they need; they can't get what
they need sooner.
Scott--follow up for Jason; does reducing the time
window have that effect, or is it OK because it doesn't
actual ration it.
Remote: Ted, newspaper and media will call it a
supersonic crash.
Chris Grundemann -- limiting amount of addresses or time
at the end, allows *more* communities to get addresses
in areas like Caribbean. less served areas will be
completely out.
Cathy, Chris' comments made her think about working
in ARIN booth at trade shows; their network will
continue to work. The great wall will happen because
they don't have translation between old network and
new network. People's customers still work, they
just can't get more.
Joe Maimon--why one group over another? The huge
companies have had huge advantages up until now;
give back time to the rest of the community.
Heather--is paul wilson still here? Presentation
said help desk requests went up 55% over past year;
are people asking about running out of v4, or
how to ask about v6?
The address requests have gone up 5% in the last
year.
But he has no idea about what the rest of the
questions was.
Leo, ISC, Cathy mentioned translation technologies,
it's not right for ARIN, but his company is working
on that translation tech. We set aside last /10 in
the last /8, but we haven't defined what those
are. Someone is going to show up and apply in
that space for a "translation" technology, we should
define it first.
Aaron Hughes--gardner--don't sweat move to IPv6;
article tells world that IPv6 is just for the
military, it's not important for everyone else.
Nov 3rd, 2 hour block to talk to Gartner about
that and correct that.
We can't always catch them in advance.
Will ARIN go to analysts to present articles to
try to get the right information out first?
Trade first, then financial analysts.
Joe Maimon; can PDP delay proposals if they
feel they are not ready for current adoption,
or must they reject for reworking?
AC can do anything to the proposal it is
deemed necessary. Decisions made in meetings
are posted to PPML, you can petition to have
your proposal voted on even if AC does not
agree.
David Farmer, UofMinn; we have been paying
attention to Caribbean region recently.
There are global political reasons to do
this. Should we set aside a chunk of space
that would make a really big deal for them,
and would probably be 5 minutes of runtime
for the rest of the region.
Rob Seastrom -- while that's a well meaning
sentiment, you're handing those folks a
millstone; shipping the garbage somewhere
else.
Martin Hannigan--they're not teensy weensy,
they're smart folks down there, and they'd
be offended we try to give them special
treatment like that.
Woody--this has come up before with LACnic
and AfriNIC; everyone would agree that as
a social matter, that would be "fair" and
"just" in some way. But that a higher
fairness and justice is served by having
everyone obey the same rules, hence the
needs-based allocation. We need to work
hard to preserve that at the end as everyone
strives in their own self-interest at the
endgame. If we suddenly throw out rules
to become generous, this opens door to
self interest on other parts.
Matt, Affilias, it's well meaning, but we've
set aside a /10 for transition technologies,
it'll serve developing areas as well; we
want them on IPv6, so focus on transition
elements instead.
Leslie Nobile--point of information about
multiple discrete networks.
Looked at v4, about 12% for ISPs are done under
multiple discreet networks.
About 300 so far in the life of the policy.
Closing mics shortly.
Closed.
No remote participants.
Close of today's meeting at 1640 hours.
Fill out your surveys.
Ted Middlestat -- thin net works, but isn't used.
transitions go faster than we expect. Faster than
we expect, IPv4 will become second class when large
content moves to IPv6 only.
yes, betamax and laserdiscs lasted after the transition,
but the mainstream moved on quickly.
They'll want it even though they don't know what it is.
Cathy responds that her point is exactly that; the
networks on v4 will *have* to translate; they won't
readdress to v6 instantly. There will be stuff you
can't get to one way or the other.
Calling all DMRs!!
VOTE NOW!!
Sponsors, Arbor and Merit.
Breakfast tomorrow at 8am, meeting at 9am
Agenda is online and in folder.
A night at the museum. 6:30 to 10:30,
busses at 6, first one out at 6:15,
then shuttles back at 8:30-11pm.
OK, now we're really done at 1644 hours!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091022/c28fc89c/attachment.htm>
More information about the ARIN-PPML
mailing list