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