<br>Here's my notes from the second half of today.  Apologies for the delay,<br>I've been wrestling with trying to get the daily survey link to work, but<br>had no luck; no love for firefox or ie on my laptop.   So, enough of <br>
trying to get that working, here's the notes.  ^_^;;<br><br>Matt<br><br><br><br><br><br>2009.10.21 ARIN 24 notes, day 1, second half<br><br>ARIN 24 resumes after lunch<br><br>John Curran welcomes everyone back at 1332<br>
hours Eastern time.<br><br>We have Advisory Council elections...<br><br>Oh, but we talk about policy 2009-6<br>first.<br><br>IANA policy for allocation of ASN blocks.<br><br>May 29, 2009, originally proposed.<br>In discussions in all regions<br>
Allows for one more year for RIRs to make<br>separate requests for 16bit and 32-bit ASNs.<br>Treat them separately until Jan 1, 2011.<br><br>No liability risk or staff issue, minimal<br>impact for implementation.<br>Assessments available online.<br>
<br>12 posts by 5 people, 3 in favour, none against.<br><br>Andrew de la Haye will present on it.<br>Currently, as of Jan 1 2010, IANA will treat it<br>as an undifferentiated pool.<br>Currently, 125 32-bit ASNs.<br>problems:<br>
45% have hardware / software problems<br>22% peering partners do not accept 32-bit ASNs<br><br>Current rate of ASN deployment will run out<br>around 2012-2014.<br><br>Current policy written when worries of earlier<br>runout seemed imminent.<br>
<br>3 options<br>do nothing<br>extend by a year (cons, less incentive to get 32-bit<br> working, we'll end up here again in 1 year)<br>or just run out of 16-bit.<br><br>This pushes for option 2; keep differentiated pool<br>
for 1 more year while we keep pushing for 4-byte.<br><br>It's under discussion or in last call in all regions<br>at this point.<br><br>No questions about it.<br><br>Scott Liebrand, Internap, he supports this proposal;<br>
we have code, we're moving forward, but it still <br>needs a bit more fixing.<br><br>Leo Bicknell, ISC, he supports the proposal; the<br>appropriate place is for LIR to put pressure for<br>this on vendors.  He wants it extended for forever,<br>
and thinks we'll be back here in a year.  But he'll<br>support it as it is.<br><br>Owen DeLong supports it; he doesn't think the year<br>timeframe matters, they won't last much beyond that<br>anyhow.  This policy helps, RIR policies he proposed<br>
didn't help much, esp. in terms of staff efforts<br>involved.<br><br>Any other comments, discussion, proposal.<br><br>Discussion closes.<br><br>People and room to do show of hands in room and <br>remotely.<br><br>One show of hands; in favour, and then opposed.<br>
In Favour: 72  Against: Zero<br>135 participants<br><br><br>Judd describes election procedures for board of<br>trustees and advisory council<br><br>Today at 3pm, after the candidate speeches,<br>voting will open, and will stay open for<br>
10 days.<br><br>Candidate speeches will be available online as<br>well.<br><br>Select 3 people for board of trustees, 5 for<br>Advisory Council<br><br>Only the 1 DMR may vote in these elections; they<br>were established on October 7th.  In good standing<br>
with ARIN, and mail on file with email domain from<br>personal account registering for it.<br><br>Voting procedures<br><a href="https://www.arin.net/app/election/">https://www.arin.net/app/election/</a><br>register (or log in)<br>
vote<br>CONFIRM your vote.  Make sure you confirm it,<br> and don't just close your browser!<br><br>Advisory Council Candidate speeches<br>(text or video available on the voting site)<br>[notes in brackets are for jogging my memory, and are<br>
 not to be taken as any type of commentary on or about<br> any particular candidate]<br>Mark Bayliss<br>John Brown<br>Rudolf Daniel (video presentation)<br>Steve Feldman<br>Wes George -- [Sprint v6 testbed, and working on v6<br>
 deployment.  No specific agenda.]<br>Chris Grundemann<br>Stacy Hughes<br>Kevin Hunt<br>Mark Johnson<br>Ed Kern--[platform is to prevent scope creep in ARIN;<br> the controls should remain with the operators]<br>Chris Morrow--[Google now, UUnet before]<br>
Bill Sandiford<br>Christopher Savage<br>Heather Schiller<br>Rob Seastrom<br>Scott Weeks<br>Tom Zeller<br><br>Next up, Board of Trustees candidates:<br>Paul Anderson<br>Scott Bradner<br>Lee Howard<br>Aaron Hughes<br>Frederick Silny (video)<br>
<br>OK, that completes candidate speeches.<br><br>So, Andy Newton will do the ARIN templates<br>presentation early.<br><br>Cathy comes to the mic.<br>A little side discussion about people working together<br>to come up with more streamlined process to clean blocks<br>
to give into free pool; we'll need to shorten the timeline<br>to less than a year.   What do people think, and who can<br>work with her on it?<br>Apparently there's a process for domain names that can<br>be a starting point.<br>
John volunteers Leslie Nobile.<br><br>Eric Kline--domain names have a process for cleaning<br>them, it takes about five days to clean up; he'd like<br>to try to develop process to do that with IP names.<br><br>Chris Morrow--Google.<br>
ARIN publishes the list of blocks that get reclaimed;<br>the current blacklist operators could follow the RSS<br>feeds; but most of them are lazy.  It's a pain to try<br>to get them take action.  It could be an exercise in<br>
futility trying to push it.<br><br>Now we have Andy Newton doing presentation on<br>retiring ARIN email templates.<br><br>Consultation sent to <a href="mailto:arin-consult@arin.net">arin-consult@arin.net</a><br>on sept 25th.<br>
 feedback on when and if to retire email templates<br> (NOT SWIP--just POC contacts, orgIDs, etc)<br><br>Consultation is about templates not backed by an<br>automated system.<br>ORG/POC templates<br>requests for new resources<br>
non-automated<br> ARIN seldom processes them automatically<br> likelihood for human email exchange<br> not conducive for automation<br><br>Email is insecure<br> 234,246 POCs<br> 19 use X.509<br> 48 use PGP<br>adoption of security measures is very low<br>
SPAM clogs inboxes, filters catch replies<br>non-interactive<br>non-intuitive<br><br>Nothing is for Free<br>there are costs to continuing dual operations<br>maintenance<br>training/support<br><br><br>Engineering time to fix bugs<br>
ops staff to keep systems running<br>continued management of certificate authority<br> security practices<br> key rollovers<br><br>Training and support<br>help desk needs to understand both systems<br>training methods and docs need to list both<br>
for new users, email templates add to array of confusion<br><br>New development conflicts<br>slows data model changes<br>new systems must accomodate legacy behaviour<br>legacy systems do not know about newer systems<br> IRR wall<br>
 inflight X tickets<br>considerably slows new development<br><br>Adoption curve for POC curve; web pretty<br>much always higher<br><br>Online experience<br>immediate feedback through web forms<br>new X tickets can be tracked by users<br>
Online help.<br><br>Online reporting, users can view their related records<br>and resources<br><br>Security<br>ARIN Online requires password authentication over HTTPS<br>Mitigates hostile POC takeovers<br> POCS lead to ORGs which then lead to the keys to the<br>
 kingdom, resources<br><br>What should we do?<br>should new development be slowed by legacy systems?<br>Given that users are switching to ARIN Online, should<br>users who wish<br><br>Give feedback<br><a href="mailto:arin-consult@arin.net">arin-consult@arin.net</a><br>
<br>Aaron Hughes--he sent objection about SWIPs.<br>he tried to log in, and got error about the system<br>being down.  This has to be 100% reliable in order<br>for this to be acceptable!<br>A: Well, email isn't 100% reliable either, and they<br>
have to work with helping people on their templates.<br><br>OK, so templates can't be phased out until track<br>record is more reliable.<br><br>Joe Mamon likes paper trail; he would like email<br>to be kept active until disuse shows it ready for<br>
retirement.<br><br>Martin Hannigan uses this and only this to handle<br>records; he likes the export function to do audits<br>of his space.  It's likely SMTP had issues for Aaron<br>that were transparent to him, if he'd checked his<br>
queues.<br>Concern about fees being needed to <br><br>Peter from Cablevision--ran into issue with<br>signing POCs to ORG-IDs--will that process<br>be functionally available?  <br>A: That feature is now active on website.<br>
<br>Arcadia speaker at mic--people still use email<br>system for a reason; make the new system usable<br>so people have no reason to use email system.<br><br>Leo Bicknell applauds new system, and thinks that<br>time to deprecate email when statistics show that<br>
users have moved to new system, and have largely<br>moved off the email system.<br><br>Joe, comment--also possibility that unsecured<br>templates could be deprecated, and only PGP<br>or X.509 be accepted.<br><br>John asks if there's reliable, stable ARIN Online<br>
with widespread adoption, would they still need to<br>keep the email system around?<br><br>Scott Liebrand, Internap--early comments are in line<br>with what he was going after.  We need a paper trail<br>through the online system; don't make everything<br>
hostage to web internal system; provide copy to<br>people at each transaction.<br><br>Rob Seastrom--how adopted is widely adopted and<br>how much time would you give it? <br>Substantial outreach time is needed to let the<br>
community know that we will be phasing a mode<br>of access out.<br>The number to start with should be single digit<br>number of years.<br><br>Owen DeLong, <a href="http://he.net">he.net</a>, doesn't feel that retiring<br>
the templates is valuable; it's just another way<br>to get data into system; he would propose the<br>system should be able to take templates in, and<br>be able to process them into the new system as<br>a parallel input.<br>
<br>Scott Bradner says we need to watch the numbers;<br>if people are still using it, giving an arbitrary<br>deadline will annoy people.  <br><br>David Farmer, U of Minn--a suggestion from cyberspace<br>that we deprecate insecure templates.  Let's do that,<br>
and raise the security of the system as a whole, and<br>may be the way to thump the system.<br><br>Aaron Hughes--one quite useful way to promote webservice<br>is to add autoresponder at top of emails listing the<br>URL for the new service, alerting them of the new<br>
system.<br><br>Rob Seastrom notes it won't get to everyone, even<br>though it's a great idea.  And at the top, note<br>that they're using a deprecated system that will<br>be going away eventually.<br><br>Stan Barber, ThePlanet--Would there be programmatic<br>
interfaces to this, like XML?  For ORGs and POCs.<br>A: nothing on the roadmap about doing those.<br>At last meeting, they talked about SWIP templates,<br>and decided they'd have to do at least that.  They<br>have some ideas, they might be able to extend to<br>
regular POC and ORG forms.  Being able to create <br>ORGs and POCs for customers would be good.<br><br>Kelly, utah edu network.  What about server maintenance,<br>full redundancy, downtime, fault tolerance, etc.<br>email has store-and-forward to deal with service<br>
interruptions.<br><br>Kevin Oberman, ESnet--does ARIN website meet ADA<br>section 508?  <br>A: Yes, it does, they have an external<br>agency that helps with testing and verifying that.<br><br>Now it's breaktime!!<br><br>
Info center up there, meet staff, watch videos,<br>help desks are open, billing helpdesk is available<br>by appointment, and don't forget to vote, it closes<br>at 5pm for NRO!!<br><br>For DMRs, if you're using same email, you'll see<br>
all entries under that domain on same voting page.<br><br><br>John Curran starts us up after break at 1532 hours<br>Pacific time.<br><br>Mark Kosters is up next to talk about LAME testing<br>and next steps.<br><br>ARIN has been doing LAME DNS testing for some time<br>
now.<br><br>Lame delegation process<br>delegations tested daily until test good or<br>removed.<br><br>If still lame after 30 consecutive days of testing,<br>POCs notified<br><br>If still lame 30 days after initial notification,<br>
POCs notified again.<br><br>If still lame another 30 days after that, delegation<br>is analyzed manually, nameservers stripped if delegation<br>determine to be wrong<br><br>LAME:<br> no A record for name server<br> not responsive (times out)<br>
 doesn't think it's authoritative for reverse zone<br>  (no A bit) <br> no SOA record for reverse zone<br><br>Leslie provided following report at ARIN 22<br>problems observed--no clear way of detecting a lame<br> delegation<br>
potential legal liability<br>operationally significant time spent on development,<br>notification, and followup<br><br>Service issues with current lame system<br>turning off working delegations<br> delegations in dns for a /16 when they have a /19<br>
 incorrectly configured DNS servers<br>substantial customer support<br><br>John challenged him to come up with a better<br>way to define lame.<br><br>3 tests:<br> Issue an SOA query for the delegation; if server<br> responds, delegation is good.  Note that AA bit<br>
 doesn't have to be set on the response<br><br>If that fails, fill out the dotted quad for the<br> delegation, issue a PTR request; if the AA bit<br> is set, the delegation is good.<br><br>If test 2 fails, provide 3 random PTR queries for <br>
 dotted quads that reside in the delegation; if any<br> of three tests gets an answer, the delegation is<br> good; note AA bit does not need to be set<br><br>Consensus--is relaxed algorithm worthy?<br><br>Leo Bicknell--ISC; comments in 2 directions.<br>
this is hard to define, it would be useful for<br>ARIN to actually define what they *expect* of<br>people who run nameservers to.  It is much<br>easier to tell them they were removed due to<br>failing tests, if we first explicitly list <br>
what their requirements are for running a DNS<br>server.<br>Also, people throw into lame 2 problem.<br>LAME--down the tree server replied with a reply<br>that the up-the-tree server didn't agree with.<br>But that's predecated on a response.<br>
Servers that are non-responsive (missing) is<br>a totally different problem, and should be<br>addressed differently.  The non-response<br>problem could be an issue with ARIN routing,<br>the internet at large, etc.<br><br>
<br>Some dude at back mic talked about not liking<br>point 3, as during a transition, the response<br>coming back will be from an unexpected server.<br>Would be good to have a tool on website so that<br>people can perform self-test to make sure that<br>
their DNS server is working properly.<br>A: If you do transfer, you update your NS set<br>first for it; so people in that part of the<br>tree should still go to the right servers.<br><br>Oh, he was talking about the reverse zone, in<br>
case your upstream still has records for your<br>/19 within the /16.<br><br>What is TTL of delegation from ARIN to space<br>holder?  2 days?  That could cause operational<br>issues for email holders, for example.<br><br>Center front, Andrew--if there's an org that<br>
considers their blocks private, don't allow<br>external queries, but it works fine on the<br>inside?<br>A: some entitities do have internal blocks,<br>and they flag those delegations; the pain point<br>they try to address is ones visible to the<br>
external internet.<br><br>Leo Bicknell--ISC--curious, thinking forward a<br>few days; reverse zone DNSSec signed, will this<br>check DS in parent vs child, and if mismatches<br>there would count as lame?<br>A: good point, but let's solve this first.<br>
<br>Q: in that case, before the reverse zones are<br>signed, ARIN should publish the rules for DS<br>keys in a zone, and if action will be taken<br>if DS keys are out of synch.  At least one<br>key must validate signatures for validating<br>
servers to work; should cases of no keys<br>matching be considered LAME or not?  Define<br>it!<br><br>David Farmer, U of Minn, the changes being<br>proposed are reasonable, need to think about<br>them a little longer; suggestions for process.<br>
This might be something we work with RIR<br>brethern, and put an informational RFC, or<br>a BCP document.<br>A: definitely, we'd like to expose this to<br>the other RIRs, to get more people aware of<br>it.  But we want to get it working within <br>
ARIN community first, definitely.<br><br>Not everybody's day job here is working with<br>DNS; mostly people here are router people.<br>Might be good to get people with DNS as they<br>day job.<br><br>Final comment, OwenDeLong, He.net.  He'd like<br>
to not redefine LAME; he does like these as<br>criteria for what gets removed or not removed<br>from the zone file, and publishing these as<br>rules for people to follow.  DNSSec is likely<br>to force this issue along as well.<br>
<br>Will this be done for ip6.arpa as well?<br><br>Will be thinking about it.<br><br>Draft policy 2009-7, open access to IPv6.<br><br>Proposed 29 May 2009, draft 31 Aug 2009,<br>under discussion in other registries.<br><br>
Removes requirement to advertise the single<br>aggregate, and removes requirement to be ISP<br>in ARIN region.<br><br>legal risk; could encourage fraud.<br><br>staff concerns; leaves only qualification to be<br>an ISP to get space.<br>
<br>Could be unfair to end sites, which would need<br>to justify a /48, but could easily get a /32.<br><br>Excerpts from PPML discussions are citing.<br><br>Now over to Cathy to present.<br>This was a very old policy, written a very long<br>
time ago.<br><br>She started rewriting the policy for the Carribbean<br>region, and then thought it might be good to apply<br>to everyone.<br><br>Most regions changed original language anyhow early<br>on.<br><br>Policy statements<br>
removes the "advertising single aggregate"<br>and removes "200 site" requirement.<br><br>Pros:<br>promotes IPv6 adoption<br>facilitates innovation and progress<br>currently can't announce more specifics for traffic<br>
 engineering<br>current policy doesn't allow for more specifics for<br> anycast<br>current policy doesn't allow for more specifics to<br> fight a hijacked /32.<br><br>Cons:<br>routing table growth<br><br>Anyone want to say anything.<br>
<br>Marla from FT.<br>She wants to take the /32 aggregate out, that<br>part doesn't belong.<br>She isn't sure the 200 part should be taken out,<br>as per the legal advisory about the abuse concerns.<br><br>Aaron Hughes; looking for clarification from legal<br>
on this; is same text provided for v4 space?  This<br>seems to protect resources from people lying?<br>wouldn't v4 need similar protection language?<br><br>A: Steve said not fatally flawed...<br>He understands goal we're trying to achieve, but it<br>
opens up policy to allow lots of unsavory people to<br>get space with the changes.<br><br>Aaron does support the policy.  As a new organization,<br>he had to acquire v4 space to build a v6-only network.<br><br>Doni from PeakWeb supports the policy.  The current<br>
policy leaves a portion of our membership stranded.<br>Ah.  This policy change does remove the "known ISP"<br>part removed.<br><br>And Aaron would be happy with it with 200 sites<br>still in it, but "known ISP" removed.<br>
<br>Doni notes that smaller networks with less than 200<br>still have to lie.<br><br>Dan Alexander, Comcast.  Cathy said these were removed<br>from other RIRs; do the other RIRs have criteria they<br>put in place of these, or are they as liberal as the<br>
proposed language would be?<br><br>RIPE says they got rid of 200 end sites, and the<br>ISP requirement is gone.<br><br>APNIC was proposing to strengthen aggregation by<br>pushing for additional aggregation, but that was<br>
defeated.  End site requirement is still there.<br><br>LACNIC removed 200 sites; they ask for aggregate<br>to be announced within 1 year, and to provide<br>service within 2 years.<br><br>Kevin Oberman, ESnet--likes half, not likes the<br>
other half.  First change, allowing de-aggregation<br>isn't about open access to IPv6.  The second half<br>is entirely too liberal to do all at once; but we<br>need to take smaller steps to get there, not just<br>open the door to anyone who can breathe and send<br>
email.  It's just a bit *too* liberal.<br><br>John someone, it strikes him the panel at IPv6<br>panel is that there's a problem with current policy.<br>The idea of having to consume some scarce v4 resource<br>to get unscarce v6 resource is just wrong, and needs<br>
to go away.<br>No limitations on getting space at all abrogates our<br>stewardship of scarce slots in the routing tables.<br><br>Cathy responds noting that ARIN does not dictate to<br>operators what routing policy should be.<br>
<br>This conversation at open mic last night...there's a<br>difference between between "there can be only one"<br>and "there are no constraints"--can we find something<br>in between that allows for good operations as well<br>
as good stewardship without throwing the gate wide<br>open.<br>If you get a lot of growth very fast in IPv6 routes,<br>and don't constrain it, the fears of gradual growth<br>people worry about will be nothing compared to worries<br>
of routers falling over.<br><br>Jason Schiller--clarification question; confused on<br>6.5.1.1b; it says "be known ISP *or* to provide 200<br>customers in next 2 years"--if a new entity starts<br>up with 200 customers, is not a known ISP, would they<br>
get addresses.<br><br>Aaron notes he was denied on that count; he requested<br>a /32 for 200 customers over the next five years, but<br>was not a known v4 ISP.<br><br>Currently, the language requires ARIN to evaluate the<br>
stated business plan and make a value judgement.<br><br>Jason is still confused if we have a policy problem,<br>or an implementation problem?<br><br>If you apply, you will need to submit a business plan<br>that shows how you will get those 200 customers.<br>
<br>In that case, he is opposed to this policy, as the bar<br>is sufficiently low; with no requirement, the bar is<br>too low, and even his house would qualify as an ISP.<br><br>Igor, Yahoo--completely for part 1, and feels that it<br>
is a hinderance to development of the IPv6 internet,<br>especially for content providers to develop this.<br>And please leave operational problems to operators;<br>the operators will take care of the routing table<br>size issues.<br>
As far as part 2; really wish we could vote on part<br>1 separately. <br>Is fee schedule for ISP separate for end site?<br>Those fees are waived now, and will expire or be<br>extended on December 31st.<br><br>If you apply for v6 only; end users pay 1 time fee,<br>
and then nominal maintenance. <br>ISPs pay for allocation, and pay same amount each<br>year on their total allocated block.<br><br>Couldn't the fee be used to disincent abuse of<br>the system?<br><br>Joe says we need to have a better end site plan.<br>
<br>Scott speaks for Chris--says single aggregate is bad,<br>need to remove it.  He doesn't think dropping 200 end<br>site would be good.<br><br>Leo Bicknell ISC, first half he agrees with, it doesn't<br>reflect reality, and operators are better poised to<br>
react as needed to changes, as routers grow, etc.<br>Second half of proposal; agree that given Aaron's<br>type of situation, the current situation is very flawed.<br>We need to set a reasonable criteria for the bar at<br>
some level.<br>Right now, interest in v6 is low; few people will<br>start up v6 only businesses.<br>However, over time, that will become more interesting.<br>Transition may happen quickly.  If we remove all limits,<br>we could have hundreds of thousands of people trying<br>
to get space in too short a time for policy process.<br>The problem of people not being able to qualify with<br>real plans is real, but he doesn't support the second<br>part as it stands.<br><br>Owen DeLong, <a href="http://he.net">he.net</a>; he feels 200 end site is too<br>
steep.  Some requirement is worthwhile.  Would be<br>good input to AC if we can get a range sense of what<br>a better bar should be.<br>otherwise, good policy, the removal single aggregate<br>are needed.<br><br>random person at mic agrees part 1 needs to go away,<br>
otherwise the /32 used for anycast is stupid, the<br>reasons for it are solid.<br>For part 2, we have other things we require in v4<br>for doing this; can we tie v6 rules to same boundries<br>and qualify for it to get v6, but not actually take<br>
it.<br><br>Kevin Oberman, in response to tom, current policy<br>does not require you to get IPv4 space before getting<br>IPv6.<br>Stewardship in terms of forwarding table sizes is<br>not an ARIN issue, and that is a constantly sliding<br>
bar.  The economics will control how networks are<br>run, regardless of what policies ARIN sets, as one<br>network rejects prefixes that ARIN allocates today.<br><br>Igor from Yahoo--given that many people are in favour<br>
of part 1, and more discussion is needed for part 2;<br>can we split it?<br>They can poll the two parts separately, and AC can<br>take that under advisement.<br><br>So far, nobody has said the routing aggregate part<br>needs to stay; if you support that, please go to the<br>
mic!<br>And if you'd like to see a requirement for the<br>block to be announced within a certain period of<br>time like LACnic, please speak up.<br><br>David Farmer, UofMinn, he supports first part of<br>policy, he echoes discomfort with lack of criteria<br>
for part 2.<br>And proposals for working on end user part of<br>assignment policy will be forthcoming; it is on<br>the list of policies that will be worked on <br>very soon; he will be working on it shortly, so<br>please talk to him if you have ideas about it.<br>
<br>While he agrees that operators are more than<br>capable of setting and defending policies, he<br>feels ARIN is responsible for providing hooks<br>for providers to hang their policies on.<br><br>John will close mics shortly.<br>
<br>Chris Grundeman, he would support splitting policy<br>in two, and supports first half.  If ARIN wants to<br>preserve table slots, start allocating sparsely!<br><br>For second half, 200 users in 5 years is not a<br>challenge for any starting ISP; he's hit more<br>
than that as a four person ISP.  That part does<br>need more work.<br><br>Center front.  Kevin Loch, Carpathian network,<br>he supports part 1 strongly; part 2, he's concerned<br>about frivolous applications.  Economic hurdles,<br>
$2250/year with no waiver for /32; 75% waiver this<br>year, so at least $500 even today.  And you can't<br>get resources from ARIN without some legal entity,<br>some LLC, etc.?<br>A: No, does not think there is a requirement for<br>
a separate legal entity.  You must be an organization,<br>not an individual.<br><br>Kevin Oberman, <a href="http://es.net">es.net</a>; a family is an organization. :)<br>There is a difference between stewarding the address<br>
allocations to allow for rational policies, vs enforcing<br>policies.<br><br>Mike, rear mic, a minnow in a shark tank; his business<br>model is slightly different, supports medical facilities<br>across country, provides /27s and /28s right now; if<br>
he is considered a known ISP now; but if you ask him<br>to show a business plan on business model, he can't<br>meet that criteria.  As Cathy asked, he would support<br>a plan like LACNIC with time-based criteria, not size.<br>
<br>Jason Schiller, Verizon--some people may not qualify<br>for 200 sites in 5 years, and are using known ISP<br>clause as easy out to justify space.<br>how about 3 parts;<br>advertise single aggregate<br>known ISP as third part<br>
200 sites in 5 years as third part.<br>Some might support policy with combination of the<br>three items.<br>He does not support the policy.<br>Strike known ISP, and then would support it with<br>keeping aggregate in place, and the 200 sites rule.<br>
<br>That concludes discussion.<br><br>Now, show of hands; draft policy as written first?<br>In favour?  27 <br>Opposed?    48<br>in room 147<br><br>same policy; instead of removing requirement for<br>200 end sites, reduce from 200 to 100.<br>
in favour: 42<br>against:   22<br>participants, 147<br><br>Many questions about clarifying what we're voting<br>on get addressed.<br><br>What about removing only the single aggregate<br>statement, and leaving the minimum customer<br>
requirement?<br>in favour: 64<br>against:   10<br>participants: 147<br><br><br>This concludes the polic portion for today.<br><br>Open mic portion...be courteous, identify yourself<br>at the mic.<br><br>Leo Bicknell--if you attended 2 part ARIN/NANOG<br>
panel, there was near universal agreement that 2009-1<br>was hard to understand.<br>Most people didn't come up to talk about it.<br>Why didn't more people comment on it today?<br><br>Igor from yahoo notes the people who spoke last<br>
night were too hung over to make it the morning<br>to talk.<br>He'd like to see a flow chart of how it's supposed<br>to work, it's too confusing as it stands now.<br><br>Tom Daly, dynamic networks, the day job needed some<br>
love too.<br><br>Scott Bradner asks if he will take the advice for<br>putting the flow chart to make it more understandable<br>Yes, they will try.<br><br>Cathy asks if Tom Daly can explain why he finds the<br>transfer policy confusing.<br>
<br>It seems nuance of removing M&A activity didn't <br>come out at him; he might have been dense at the<br>time.<br><br>Igor, Yahoo, notes that M&A makes it confusing; is<br>it or, and, or what that; those sections seem to<br>
be in conflict.<br><br>mic open for all topics.<br><br>martin hannigan, akamai, some traffic about some<br>AC  non-comm issues; what happened, and what will<br>be done in the future?<br>A: won't be discussed during current elections,<br>
but after the elections close, will be explained.<br><br>Doni, peakweb, discussions around integrity of<br>v4 routing table and future abuses.<br>The topic is authoritative routing registry<br>that ties prefix to originating ASN.<br>
for recent v4 requests, originating ASN has<br>been added as optional field.  There are multiple<br>routing registries in use, some public, some private.<br>He would like to get feedback about developing<br>an authoritative routing registry; we would decide<br>
on which of the one would be the authoritative one,<br>and all of the others would get folded into it.<br><br>A: There are many IRRS out there; hard to envision<br>how to get to a single worldwide routing registry;<br>it's a bit bigger than just ARIN.<br>
<br>Mark Kosters, CTO, ARIN; ARIN also mirrors everyone<br>else, so even though there's islands of where the<br>information resides, you can get a comprehensive<br>view; only about 50% of the information is<br>valid in the registry.<br>
There is an emerging system getting put in place,<br>resource certification; ARIN and other RIRs are<br>testing it, <br><a href="http://rpki-pilot.arin.net">rpki-pilot.arin.net</a>, it may subsume other projects<br>over time.  <br>
<br>Right now, this is more about the certification<br>process, not the single-uber-source.<br><br>lea roberts, ARIN AC, stanford university.<br>comment on 2009-7; ARIN doing sparse allocation<br>benefit to community.  It's not a policy issue,<br>
it's implementation; could we at least space<br>the allocations out a bit more?<br><br>Anyone want to speak against ARIN doing sparse<br>allocations?<br><br>By end of meeting Friday, he will have timeline<br>for sparse allocations!<br>
<br>Lee Howard, TWC, earlier during week there was<br>a suggestion that Aaron Hughes write a best<br>current practices document around it.  Nobody<br>has figured out which space that work should<br>happen in, though.<br><br>
Should ARIN handle/facilitate this type of<br>work.<br><br>Jason schiller, Verizon; best current practices<br>document is good, but need a process like what<br>we do here, community writes their thoughts on<br>what would be best, produce a living document<br>
that changes over time; don't write what you<br>can and can't route; it's not a binding document,<br>but a best common practices document would be<br>good.<br><br>Owen DeLong, HE.net, it's a great idea to develop<br>
BCP document; set aside a new category on a wiki<br>and he can work with Aaron to develop it on the<br>ipv6 wiki.<br><br>Chris Grundeman, the ipv6 wiki on ARIN's website<br>is a good place to start; perhaps it needs a little<br>
coaxing.  We can get the ball rolling.<br><br>Aaron, a repository somewhere would be good, the<br>better place for this would be program committee<br>at NANOG; but if we start something as ARIN, it<br>won't have good operational support to make it<br>
useful.<br><br>Closing floor to new topics.<br><br>Stacy, question remotely.  If you are a legacy<br>v4 holder, must you sign legacy RSA in order to<br>get v6 resources.<br>To get IPv6 resources, you must sign RSA for the<br>
v6 resources, but v4 is not covered under it.<br><br>Cathy wants more discussion around LACNIC<br>requirements:<br>1 be LIR or ISP<br>2 document plan for services to be offered to other<br> clients, cell phones, departments,<br>
3 a single aggregate route will be advertised within <br> 12 months<br>4 offer Ipv6 services within LACNIC region within<br> 24 months.<br><br>Perhaps this would be better than our 100 or 200<br>number?<br><br>Scott Liebrand--hearing that made his head hurt,<br>
and think of 2008-2, first transfer policy.<br><br>Cathy responds that there's a large number of<br>prefixes that have never been announced into the<br>table.<br><br><br>Chris Grundeman, he talks about not needing to<br>
announce space.  We don't require that under<br>IPv4.<br><br>Cathy notes that this is for ISP policy; and they<br>require within 24 months to be reselling or<br>providing services.<br><br>Chris Morrow, Google, it would be difficult to<br>
go back and push people to announce blocks on<br>the Internet.  Making a requirement to announce<br>it is not good for large private networks.<br><br>Closing mics shortly.<br><br>Leo Bicknell, ISC, he doesn't like the word<br>
announce; but he does like a requirement that it<br>be in use within some period of time; could be<br>announced, but could also be in use on private<br>network.<br><br>Requirements like this could alleviate issues <br>like this in the IPv4 world.<br>
<br>Every 12 or 24 months, we might re-look at it.<br>There are a lot of large networks going down<br>the path to enabling their networks, and are<br>still in startup phase.  It would be silly to<br>put 12 month timeframe and spend ARIN cycles<br>
chasing cases where vendors are running late.<br><br>But it would be good verify that resources<br>are being used for *some* purposes.<br><br>Chris Grundeman notes that the customer requirement<br>does the same thing; instead of using announcement<br>
as a bar.  If you don't have customers, you're not<br>an ISP.<br><br>Cathy agrees with it, but we keep dithering over<br>the actual number.  Basically, they require you<br>to have visible customers as an ISP, where the<br>
count doesn't matter as much.<br><br>Aaron--is there anything in NRPM about resource<br>review policy for v6; there's no mandated review<br>and nothing about v6.<br><br>Scott asks if it *BLOCKS* resource review for v6?<br>
<br>It's just resources, it doesn't specify which <br>resource type.<br><br>So the legacy resources are the only exemption.<br><br>David Farmer, U of Minn, thanks to Cathy for<br>bringing this up.  We have a lot of work to do<br>
here, there's some obvious things we need to<br>move forward with on this.<br><br>Would like to thank two people:<br><br>Leo and Lea, who are leaving the AC for their<br>many years of service!!<br><br>That concludes today, you have dinner on your<br>
own tonight!<br><br>Fill out your survey online!<br><a href="http://www.arin.net/ARIN-XXIV/survey/">http://www.arin.net/ARIN-XXIV/survey/</a><br><br>Breakfast 8am, meeting 9am, it'll be like it<br>was today, and stay on target for policy proposals;<br>
other items will shuffle to make those stay<br>constant to keep the remote participants able to<br>participate.<br><br>We wrap up for the day at 1718 hours Eastern time.<br><br><br><br><br><br><br><br><br><br>