<br>Sorry, these were my "before lunch" notes, but I dashed off to<br>grab lunch before sending them out, so they're a bit late this<br>time, apologies for that.  ^_^;<br><br>Matt<br><br><br><br>2009.10.22 ARIN day 2 morning session<br>
<br>John Curran calls the meeting to order promptly<br>at 0900 hours Eastern time.<br><br>Welcome back everyone, hope you had a good time<br>exploring Dearborn last night.  Welcome back to<br>the remote participants.<br><br>
NRO election winner was louie lee<br><br>Daily survey<br><a href="http://www.arin.net/surveys/ARIN-XXIV">http://www.arin.net/surveys/ARIN-XXIV</a><br><br>today's winner is a $120 carbon offset<br>gift certificate<br><br>
Night at the museum tonight,<br>6:30 to 10:30 at the Henry Ford Museum<br>food, fun, dancing, booze, lots of cool stuff.<br><br>Get social!  If you see something good at the<br>meeting, you can post it on facebook or twitter.<br>
<br>facebook/teamARIN<br><br>Thanks to Arbor and Merit as sponsors.<br><br>Meeting rules are explained for approaching the mic<br><br>Agenda<br>IPv6/IETF/IAB report<br>RIR updates<br>NRO NC report<br>NRO activities report<br>
policy experience report<br><br>WHOIS RESTful web service<br><br>policies:<br>2009-5: IPv6 for multiple discrete<br>2009-3: IPv4 for RIR<br>2009-8: equitable runout<br><br>IPv6 IAB/IETF activities report<br>Marla will give that report<br>
<br>This is not an official IETF report; there is no official<br>liason between IETF and RIRs.<br><br>routing area work group<br>IP fast reroute using Not-via address<br><br>IPv6 maint working group (6man)<br>five documents in the workds<br>
one doc in IESG processing<br><br>V6 ops, five active documents<br>router vendor docs are being worked on to help shepherd<br>vendor CPE efforts.<br><br>also one recommending document, but non-binding<br><br>SHIM6 WG<br>little action, only one active document<br>
<br>BEHAVE WG<br>7 active documents<br>v6 to v4 translation via algorithmic translations<br>DNS64, how to deploy with v6/v4 translators<br>NAT64, NAT from v6 clients to v4 servers<br>IESG processing 2 BEHAVE docs now<br><br>
Secure inter-domain routing (sidr)<br>buttload of active documents on the slide<br>lots of what-if scenarios about what will happen<br> if ITU takes over<br>path validation being discussed, even though part of<br> another working group<br>
<br>Softwire<br>not much new in active docs<br>4 more docs published as RFCs<br><br>DNS Operations (DNSOP)<br>3 active documents<br>changing dns returns during network incidents, what are<br>ethics of it.<br><br>DNS extensions (DNSEXT)<br>
9 active<br>1 published<br><br>OpSEC<br>1 active document<br>and 1 published RFC<br><br>Global Routing Operations (GROW)<br>9 active documents<br><br>Locator/Identifier Separation (LISP)<br>new group met at Stockholm<br>5 active documents<br>
<br>Hiroshima IETF<br>Nov 8-13<br>IETF BOF wiki has info on it.<br><br>Reference, next meeting<br><a href="http://tools.ietf.org/bof/trac/wiki">http://tools.ietf.org/bof/trac/wiki</a><br><br>Paul Wilson, APNIC update<br><br>
Services<br>policy updates<br>priority activities<br>next meetings<br><br>major resource delegations at APNIC<br>IPv4 /8s growing (2009 numbers not complete)<br>ASNs may be flattening out<br>IPv6 on the rise (individual delegations)<br>
 2008 and 2009 huge growth<br><br>Service levels<br>2000 members, July 2009 largest month on record<br>for new members<br>many member LIRs, though, about a 1000 members<br>in those<br>APNIC now averages 1400+ per month helpdesk<br>
enquiries, growing over last year<br>allocations of space growing slowly, will slightly<br>exceed last year 100 per month to 105 per month<br><br>APNIC 28 policy outcomes<br>4 reached consensus, still subject to final call<br>
prop-050 -- v4 address transfer policy--receipt subject<br>  to approval according to current policies<br>prop-073 -- simplify v6 allocation to existing v4 allocation<br>prop-074 -- global policy on IANA block allocations<br>
prop-075 -- recovery of unused AS numbers in region<br><br>No consensus on 3 policies<br>prop-077 -- historical address transfer (currently needs no<br>  justification when transferring) -- proposed to require<br>  current justification<br>
prop-078 -- reserve /10 out of last /8 for v4 to v6 <br>  deployment; needs more modifications<br>prop-076 -- requiring further aggregation for v6 blocks<br>  from LIRs to single announcement<br><br>top 10 resource allocations<br>
every 2 years does member survey to assess where resources<br>should be allocated<br>1: research and dev activies<br>2: support network engineering education<br><br>...<br><br>Research and Development<br> work with other RIRs on RPKI<br>
 DNS service dynamics<br> DNSSEC implementation<br> anycast deployment<br>expand network monitoring and reporting<br> test traffic measurement (TTM)<br>  sponsorship of 12 AsiaPac nodes (part of RIPE NCC)<br> day in the life of the internet (DITL)<br>
 provided 478+ GB of DNS traffic to it<br><br>Education<br> support network engineering education in the region<br> training team active in org<br> develop institutional links<br> training lab expansion (online training)<br>
 more security training with Team Cymru<br> tunneling project with AUSCert<br>E-learning and self paced learning<br><br>IPv6<br>support more IPv6 deployment<br> coordinate and promote v6 activities across whole region<br>
 ICONS IPv6 wiki<br> IPv6 messages, materials, outreach, and information<br> IPv6 workshop for APEC TEL 40<br>  very good presence there; strong public interest in<br>  broadband.<br><br>Services<br>streamline request and allocation process<br>
MyAPNIC features<br>integrate membership sign-up and resource request form<br>automate data exchange using web services, provide secure<br> channels, link member DSNSEC signed zones to APNIC signed zones<br><br>Other:<br>
development of resource certification to support routing security<br>RPKI for members<br>more DNS root servers in AP region<br> deployments in Taiwan, Mongolia<br> deployment of TTM at root server locations<br><br>APNIC meeting<br>
Kuala Lumpur, Feb 23 - 5 Mar 2010<br>with APRICOT 2010<br><br>More APNIC meetings<br>Aug 2010, bangkok, <br><br>APNIC 31 / APRICOT 2011<br> Hong kong<br> joint meeting with APAN<br> 21-25 Feb 2011<br><br>NRO Number Council report, Martin Hannigan<br>
NRO NC, Martin Hannigan, Louie Lee, Jason Schiller<br><br>process global policy<br>appoint 2 board members to the ICANN board of trustees<br>function adminstratively; write proceedures, execute<br><br>New stuff<br>appointed Ray Plzak to ICANN BoT<br>
<br>working on global policies<br>2009-6:<br>2009-3:<br><br>Need another ICANN board member soon, too.<br><br>RIPE re-elects Dave Wilson<br>APNIC relects Dr Kenny Huang<br>See you at ARIN 25<br><br>We're ahead of schedule so we'll see if Lixia<br>
can do her demo now instead of later.<br><br>Demo of allocation vs routes<br><br>She's not looking for testers, per se; the system<br>won't handle many users.  Looking for feedback, it's<br>demoware.<br><br>Cathy Aaronson gets most of the credit; this is her<br>
second meeting; first was in 2002, when minimum allocation<br>getting moved from /20 to /22.  Cathy asked if the minimum<br>size changes, will that affect routing table size?<br>Lixia said "don't worry"--but now we have an interest<br>
in actually visualizing the impact.<br>She had one of her students do this as a project.<br>One of her other students did Cyclops<br><a href="http://cyclops.cs.ucla.edu">cyclops.cs.ucla.edu</a>, shows if someone else announces<br>
your blocks<br><br>The screen can't really show it; each block on the<br>screen is a /8<br>The fills and colours show the reserved, allocated,<br>multicast, legacy, and each RIR allocated block.<br><br>you can check the RIR allocation, and it shows the<br>
colours of how the block is allocated<br>You can keep clicking to drill in more and more<br>and eventually get down to specific records for each<br>individual allocation<br><br>More interesting bit is the "what is seen via BGP"<br>
it shows the span of BGP announcements; one allocation,<br>one announcement for 18/8.<br><br>Apple, 17/8, you see many announcements (92) along<br>with their /8 advertisement.<br><br>If you can help them figure out the best way to<br>
visualize the data on where exactly the blocks <br>are being announced, come talk to her.<br><br>Draft policy 2009-5 still isn't ready to start yet.<br><br>LACNIC update?<br>Ricado Patara<br>still growing in number of allocations<br>
membership growing; just reached 1000 members<br>staff increasing every year, up to 22 now<br><br>Membership evolution over time<br>small blocks is largest growing segment<br>1033 members<br>2 NIRs, members of NIRs are also members of<br>
LACNIC<br><br>registration services data<br>number of allocations made, v4 vs v6 vs ASNs<br>chart shows some growth in v6<br><br>policy development<br>new process (PDP) since last year introducing expedite<br> process<br>
only one meeting per year, may need faster process<br>2 co-chairs<br> francisco aria (mexico)<br> nicolas antonielly (uruguay), elected May 2009<br><br><br>Policy under discussion<br>ratified by board, to be implemented shortly<br>
 2009-01<br> 2009-02<br> 2009-03<br><br>last-call:<br> 2009-08: IANA policy for RIR allocations of ASNs<br><br>LACNIC XII meeting<br>in panama city, may 24 to may 29 2009<br>300 people from 40 economies<br><br>LACNIC Caribbean 2 meeting<br>
July 16-17, trinidad/tobago<br>70 attendees, 17 countries<br><br>IPv6 tour 2008-2009<br>visited: TT, AN, DO, PA, PE, BO, EC, CO PY, BZ, NI<br><br>Frida program<br>some money for ISP programs; call for projects finished<br>
beginning of october; soon will announce project selected<br>for funding<br><br>Outstanding Achievement Award<br>First award, Ms. Ida Holz, head of central computer<br> service of university of the republic, Uruguay<br><br>
Public affairs<br>Government working group<br> facilitate communication w/gov regarding Internet resources<br> admin<br>1st meeting held in <br><br>Organized CITEL <br>workshop on regional interconnection<br><br>+RAICES project<br>
anycast copies of f-root to be installed<br>Sint Martin most recent deployment<br><br>RPKI--issue certificate for each IP allocation<br>DNS platform upgrade/DNSSEC deployment<br>already signing <a href="http://lacnic.org">lacnic.org</a> as test bed.<br>
<br>Any questions?  Nope.<br><br><br>OK, back to policy:<br>draft policy 2009-5: multiple discrete networks<br>allows IPv6 initial and subsequent allocations for <br> discrete networks within single org.<br><br>No legal impact<br>
staff impact minimal<br><br>28 posts, 12 people<br>3 in favour, none against<br><br>Heather Schiller will do the AC presentation<br><br>proposed to solve the problem of organizations that have<br>several discrete and totally separate networks.<br>
IPv4 already allows this; this basically brings IPv6<br>into similar alignment.<br><br>Text stayed same as 4.5 for IPv4<br>except for utilization requirements<br>IPv4 has the specific utilization language.<br><br>This just requires that you show you have a separate<br>
network requirement, following criteria in section<br>6.5.2 (which you can read in your NRPM program guide)<br><br>Kevin Loch, Carpathia networks -- he does run multiple<br>discrete networks today, he fully supports it.<br>
<br>Kevin Oberman, ESnet, assuming the first part of 2009-7<br>was passed, it would completely obviate the need for<br>this, would it not?<br><br>David Williamson, tellme; if you get a single /48 as<br>an end site, if you have multiple sites, you can't<br>
really break up the /48 into routable blocks, so 2009-7<br>doesn't cover this.  He supports this policy, it sounds<br>like?<br><br>Owen DeLong, HE.net, they have many customers who have<br>expressed a need for this policy; a video delivery<br>
company for example needs this; he supports the policy<br>completely.<br><br>Leo Bicknell, ARIN AC, he supports the policy.  This<br>applies to a small number of people, but for whom it<br>is very important.<br>Can we get an idea of how many people have a need<br>
like this?<br><br>A: ARIN does not have this in any type of stastical<br>model, right?  Leslie notes that she does have the<br>data, it's just not auto-accessible.  Will it change<br>his answer?<br><br>Cathy Aaronson, Cascadia, she responds to Kevin about<br>
why removing /32 aggregate requirement doesn't help.<br>She had 2 divisions with 2 different business models;<br>one was mostly utilized, the other barely used; she<br>couldn't split the /32 into 2 /33s, she really did<br>
need a second block for the second network.<br>She is totally in support of the policy.<br><br>Andrew Dul, wrote original v4 proposal, he supports<br>the v6 proposal; it did make things easier for ARIN;<br>it is about the way companies do business today.<br>
ARIN needs to foster v6 on the internet, we need<br>to support companies in their ability to do business,<br>and this is one way in which companies do business.<br>In terms of removing single /32 announcement, he doesn't<br>
think this solves it either, same reasons as Cathy.<br><br>Kevin Oberman comes back and after Cathy's explanation,<br>he now supports this fully.<br><br>Jason Schiller, Verizon, he is in favour of it even<br>though it does add more routes into the global table.<br>
He can see a need for this for multiple stub networks;<br>it should not lead to a large increase in global routing<br>tables.<br>In v4 flavour, there is a requirement where the overall<br>utilization of all discrete networks is looked at.<br>
It is not clear if the v6 policy should have the same<br>language; but it's not clear if we should have same language,<br>but we may have a check to make sure earlier allocations<br>are being used.<br><br>David Farmer, U of Minn--is it staff's opinion that this<br>
applies to end site as well as ISPs?<br>A: Yes, applies to both.<br>Then he does support it.<br><br>If you are against this, speak up.<br><br>Joe Maimon, remote comment; policy as written appears<br>to prevent opening the floodgates,...[I lose last part,<br>
as scott is speaking too quietly and quickly to make out.]<br><br>microphones are now closed.<br><br>Now we vote on 2009-5:<br>in favour: 79<br>opposed:   zero<br>total in room and remote: 146<br><br>ACSP<br>Open consultation question and answer process;<br>
a quick summary of these will be coming up momentarily<br><br>This is basically a suggestion box<br>provides a formal mechanism for the community to suggest<br>change or additions or suspension of ARIN services or practices<br>
<br>This allows for public view for issues, to make sure that<br>a formal response is issued.<br><br>There's also staff initiated questions that are raised to<br>the community<br><br>Changes to ARIN resource revocation procedures<br>
Should overdue period be shortened to 6 months<br>from 12 months before address block is reassigned.<br><br>At 6 month mark, it would be revoked, and be<br>announced to the community in a feed; that way,<br>it would be in hold-down for six months before<br>
getting re-assigned.<br><br>Comments on this are welcome.<br><br>Changes to ARIN RSS feed<br>add daily recovered address space to the RSS feed<br>should it be extended to provide data in XML to allow<br> for programmatic sucking into databases?<br>
but that could be an announcement of blocks open<br>for hijacking.<br><br>Retiring ARIN email POC templates<br>It's out there, we talked about it yesterday.<br><br>Please feel free to put comments on ARIN discuss<br>mailing list.<br>
<br>Break time, talk to info center, see materials,<br>election help desk is open, billing help desk is<br>open, be back at 11.<br><br>BREAK TIME!<br><br>We come back from break, and jump into the NRO<br>activities report from Adiel Akplogan<br>
(Numbers Resource Organization)<br> RIRs working together<br><br>Current office holders<br> Adiel, Axwl, and Raul (AfriNIC, RIPE NCC, LACNIC)<br>NRO coordination groups<br> ECG (engineering)<br> CCG: (communications coordination)<br>
 PCG (public relations)<br><br>NRO expense distribution 2008<br> AfriNIC 3.2<br> APNIC  26.5<br> ARIN   27.3<br> LACNIC <br><br>ICANN meetings<br>Mexico City, 1-6 March 2009<br> present status of IPv4, IPv6, what we're doing about it<br>
 <br>Future meeting next week in Seoul<br><br>Internet Governance Forum<br>NRO-EC represented in MAG (Raul Echeberria)<br>Next meeting, Nov 15-18 in Egypt<br><br>International cooperation<br>ITU<br> provide internet number stats to ITU members<br>
 participate in Telecom World<br> Meeting with ITU to understand IPv6 address management<br>OECD<br> NRO has joined ITAC<br> contributing to several OECD meetings<br><br>Timeline for IPv6 support by RIRs<br>ip6.arpa delegation planning<br>
DNSSEC planning<br>resource certification coordination<br><br>Addressing IPv4/IPv6 issues<br><br>Retreat outcome<br>Create new public affairs coordination group (PCG)<br>decided on some permanent distribution of some NRO functions<br>
CG chairs and EC chair to come from same RIR starting 2010<br>Agree on limiting ASN 2-byte allocations to RIRS to 2 per RIR.<br><br><br>Update from the RIPE NCC<br>Vital statistics<br>6388 members<br> over 1000 members from russia alone<br>
Budget of 15.2M EUR<br>staff: 112<br>stable board composition<br>long term improving efficiency<br><br>Planning for 2010<br>general meeting in october<br> draft activity plan/budget (17.5M EUR)<br> draft charging scheme (slight rise next year)<br>
articles of association<br> simplify election proceedure<br> enable e-voting for remote participation<br><br>Yet another k<br>k-root node in Africa deployed.<br>Will talk to LACnic about south america<br><br>TTM partnership with APNic<br>
 new node in pakistan, more to follow<br>BGPviz<br>RIS backend arch improvements, 10x faster<br>Hard at work on new portal<br><br>Customer service highlight<br>remember 2007-01<br> get a grip on those PI assignments<br>As per 24-08-2009<br>
1935 out of 4900 registries have participated<br>9101 out of 27k resources have status set<br><br>Training and IPv6<br>IPv6 testimonials (interviews with members from the<br> community about their experiences with IPv6<br>
 published on IPv5ActNow and Youtube<br> short per-topic cuts<br><br>e-learning news<br>DNS SEC e-learning<br> first module published<br><br>Science group<br>making progress on quality and consistency of mostly<br>historical registration data.<br>
<br>new tools:<br>REX (resource explorer)<br> dig up historical records for past 10 years on block<br>Netsense<br> status of internet<br>INRDB<br><br>RIPE Labs<br> Robert Kisteleki<br>Forum for presenting new ideas and tools<br>
<a href="http://labs.ripe.net/">http://labs.ripe.net/</a><br>launched at October RIPE<br><br>still getting the bugs worked out, it can<br>be a bit slow at times, but coming along nicely.<br>Not meant to be RIPE NCC, but for whole community<br>
<br>External relations and communications<br>donated sizeable amount of paul rendeks' time to<br> NRO for PR and Comms effort<br>Also, secretariat support for ASO (heavy hit on <br> resources)<br>strong support for EU IPv6 survey<br>
 600 responses<br> similar to previous ARIN study<br> recently completed by APNIC<br><br>Outreach<br>17-18 sept, Moscow<br>21 setp roundtable for gov't and regulators<br>22 sept LEA Workshop<br>5-9 october RIPE 59 as well as ITU telecom World, Geneva<br>
<br>Meetings<br>regional meeting in beirut, 28/29 October<br>RIPE 60 (3-7 May 2010)<br><br>Suggestion--next year, warm up the room!!<br><br><br>Draft 2009-3: Global policy, allocation of <br>Similar in every region but ARIN; adopted in other regions<br>
or in discussion.<br>Does it help to have a global policy that's different<br>in each region?<br><br>Don't get hung up on exact wording, we may need to<br>adjust a bit with ASO<br><br>Original proposal required return of address space to<br>
IANA.<br><br>ARIN required legacy space to go to IANA, other space<br>return was 'optional'; <br><br>reworked it; now says RIRs "may" return space to IANA.<br>New IANA to RIR IPv4 allocation policy; 1/10th of IANA<br>
free pool to each RIR upon request, every 6 months<br><br>No legal risk<br>staff concerns; fractured /8s, serious reverse DNS<br> concerns<br><br>staff concerns; will take more work, but won't be<br> impossible to do.<br>
<br>54 posts, 15 people, <br>1 in favour, 5 against<br><br>If we use term "may", it becomes suggestion rather than<br>policy; better places for suggestions.<br><br>Once the free pool is exhausted (IPv4), no policy for<br>
IANA redistributing blocks smaller than /8, or for RIRs<br>to share/transfer between them.<br><br>This creates a new global pool of returned space that<br>can be divided among RIRs.<br><br>The concerns mainly focus on the mandatory return of<br>
the full block.<br><br>The policy was revised to only return if it was<br>designated for return under local policies or<br>proceedures.<br><br>any space designated for return would still follow<br>the same formula as originally proposed.<br>
<br>concerns: reverse dns implications for fractured /8s.<br>Now you delegate all the sub-blocks.<br>Not an insurmountable obstacle.<br><br>Should we be fragmenting returned space among RIRs?<br><br>Possibly this policy won't get much use since it's<br>
optional, so why bother<br><br>Should we move it forward/why?<br>avoid having smaller returned space get stuck in IANA<br>because it's less than a /8<br>provides mechanism to move space between regions if<br> appropriate<br>
<br>All the other RIRs want to do this, let's show them<br>that we want cooperate in good stewardship<br><br>provides more flexibility for working with reclaimed<br>space in the future.<br><br>Floor is open for discussion of policy 2009-3:<br>
<br>Leo Bicknell, ISC, thinks concepts involved are of paramount<br>importance; we need to get space back from RIRs back to IANA.<br>But original policy and amended policy go about it in the<br>worst possible way, and create many problems for NRO.<br>
Policy combines policy to give space to RIRs (global<br>issue, needs all 5 RIRs), with problem of RIR returning<br>space to IANA (a local issue within each RIR).<br>second thing, ommission in original document, no requirement<br>
that IANA use needs-based allocations.  He thinks that there<br>needs to be clear text explaining the rules behind it)<br>He opposes both the original and proposed change.<br><br>Owen DeLong -- HE.net -- creating problems for NRO isn't<br>
a reason to object to a policy.  The policy makes it up<br>to each RIR to return space as they see fit.<br>Can we put policy into process with NRO, and then let<br>NRO work it with the other RIRs to see if they want to<br>
adopt it with changes proposed<br><br>Martin Hannigan, Akamai, he is opposed to policy, feels it<br>is lipstick on the pig.  RIR transfer policy is the heart<br>of matter.  A global transfer policy would be a better<br>starting point.  This is a problem in that it applies to<br>
just legacy space; needs to apply to all IP space.<br>Fulfillment concern; at 10%, some may <br><br>Joe Maimon CHL--if ARIN is only one to adopt with optional<br>"may" clause, won't other RIRs call foul?<br>
<br>John notes that ARIN "won't" return space due to "may"<br>clause, it simply doesn't mandate it.  Historically in<br>this region, we've returned space; but that's no<br>guarantee of future behaviour.<br>
<br>Scott notes that there are two things global community<br>wants to accomplish; handle redistribution of space,<br>and provide pressure on all RIRs to consider global<br>needs not just local needs when returning space.<br>
Impression is that other regions would rather have<br>structure set up with optional return; this wouldn't<br>hurt us, and would help provide that framework.  <br><br>Paul Wilson, APNIC -- transfer policy in APNIC<br>
requires that recipient justify space they wish to<br>receive based on requirements.  That is essentially<br>needs-based policy, in compliance with ARINs policy.<br><br>After run-out, the policy is no longer needs-based.<br>
<br>Martin --historical precedent seems to refer to 46/8, <br>47/8, 50/8; references chosen strategy,<br>do we really need a policy to identify chosen strategy?<br><br>Scott--don't believe there's a way we can modify this<br>
proposal in a way that would make it better.  We can<br>either support, or reject, in which case the global<br>policy fails.<br><br>Lixia--the one fact people may not be aware of, routing<br>could make use of which /8 is allocated to which RIR for<br>
doing route aggregation.  From North America to Asia, only<br>a few exits, so aggregating /8s to regions could be used<br>to help the global routing table.<br>She is not in favour of it.<br><br>Paul notes the transfer policy is in final call, this<br>
policy is still under discussion. <br>If this policy were adopted, IANA would still have a<br>set of address to allocate, so "runout" would not have<br>actually occurred.<br>If there is address space at IANA being addressed by<br>
this, then runout has not happened.<br>If we "runout" and then more space it appears, it's<br>not clear if we flip back to 'pre-runout' language<br>or not.<br><br>John at rear mike--the perception that the RIR system<br>
of separate regions with bottom up policy building<br>is incapable of fairly sharing across the globe is<br>used in arguments that are detrimental to the RIRs.<br>There may not be much of this space to return<br>anyhow; it may be that more damage is done to the<br>
structure of the RIR system by worrying about the<br>possiblity that some space may move away from ARIN<br>than actually having space move.<br><br>Martin Hannigan, Akamai, at any point without a global<br>policy, any RIR could change their policy away from<br>
this.  For second point, cooperating globally is<br>good; but there's an expectation that everyone play<br>by the same rules.  From a business side, there are<br>concerns about costs related to this.<br><br>Mics will close shortly.<br>
<br>Jason Schiller, Verizon, clarify Paul's point.  This policy,<br>and other flavours, seem to set up a *new* pool called the<br>recovered IPv4 pool.  It seems that according to 10.4, the <br>existing policy phase is done through the IANA pool.<br>
If addresses get returned prior to depletion, they will<br>go into recovered pool, and cannot be touched until the<br>IANA pool empties, we move into exhaustion phase where<br>1 final /8 is given to every RIR; at that point, we<br>
are post-runout, and those rules apply.<br><br>The trigger condition in APNIC 50 for when they can no<br>longer receive additional space; until commencement of <br>use of final /8 is the trigger; if they get final /8,<br>
but use RIR recovered space in the meantime could last<br>a while.<br><br>Joe Maimon, CHL, without mandatory return, policy<br>has little harm, but also could be useless under<br>scarcity pressure.  Would also support policy<br>
with return size greater than RIR 6 or 12 month.<br>The concern about size of legacy space is also<br>a concern.<br><br>mics are now closed.<br><br>Leo Bicknell ISC -- can you clarify why these go into<br>recovered pool instead of IANA pool?<br>
<br>John notes that there's a specific allocation algorithm<br>on how to evenly divide up the space when regions have<br>unequal draw rates.<br>Designed to have even distribution over time; that<br>can't happen unless it goes into a specific pool with<br>
specific rules.<br><br>Jason Schiller, Verizon; if we vote this down, indicate<br>why we don't like it, so it can be documented so that<br>other regions can work to address the concerns.<br>If we vote down either original policy or the proposal,<br>
we should explain why.<br><br>Voting on draft policy, 2009-3:<br>in favour: 21<br>against:   26<br>voting members, local and remote: 146<br><br><br>Regardless of which way you voted, talk to the AC members;<br>let them know what you think; they have a very difficult job<br>
to do on this one!<br><br>It's time for lunch, 90 minutes; we're going to be at lunch<br>until 1330, on second floor in Bistro; take your valuables<br>with you, no security here.<br><br>LUNCH!!<br><br><br>