ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week)
NANOG Community - There is an Draft Policy for Inter-RIR Transfers presently in extended "Last Call" in the ARIN Policy Development Process. The Last Call will run for one more week, and allows an opportunity for anyone in the Internet community to provide feedback regarding this proposed number resource policy. Feedback, including statements in support or opposition, may be sent to the ARIN Public Policy Mailing List "arin-ppml@arin.net<mailto:arin-ppml@arin.net>" (http://lists.arin.net/mailman/listinfo/arin-ppml to join or view archives) A copy of the Last Call announcement, including the most recent changes and draft policy text, is attached to this email. Feel free to forward this email to anyone in the Internet community that you feel may wish to comment in support or opposition to this draft policy. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN <info@arin.net<mailto:info@arin.net>> Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call Date: October 19, 2011 3:11:59 PM EDT To: arin-ppml@arin.net<mailto:arin-ppml@arin.net> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to send an amended version of the following draft policy to an extended last call: ARIN-2011-1: ARIN Inter-RIR Transfers The AC provided the following statement: ******** The Advisory Council reviewed the results of feedback from the ARIN XXVIII Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR Transfers. While there were concerns regarding the presented wording, there was significant continued support for a policy enabling Inter-Regional transfers of IPv4 number resources from organizations able to make them available to any organization with valid requirements. In addition to cumbersome wording, the presented text could not be cleanly inserted into the NRPM. The following is new language that directly modifies section 8.3 "Transfers to Specified Recipients" to allow such transfers to or from organizations in other regions. The first paragraph is a modified version of the current 8.3 policy language, envisioning resources being released to ARIN by the authorized resources holder or additionally by another RIR to be transferred to a specified recipient. The second sentence was reorganized to emphasize that it applies to an organization within the ARIN region that will receive such a specified transfer, and to eliminate the single aggregate language per 2011-10 which is also being sent to last call. The new second paragraph adds language enabling transfers to a specified recipient in another RIR's service region. This language specifies that such recipients justify their need to their RIR, following that RIR's policies. ARIN will verify that there is a compatible needs based policy that the other RIR will use to evaluate the need of the recipient and that both RIR's agree to the transfer. Implicit in the intent of the language presented and in conformance with statements made, the size of the block to be transferred is identified as /24 or larger, for obvious practical reasons. In accordance with concern for immediate adoption, the AC chose to forward this version to last call. Concerns expressed by some stakeholders for further controls were noted by the AC, and are being considered for future policy modification, assuaged in part by ARIN staff assurances that if any significant abuse of this policy were to occur, then the policy could easily be suspended. The AC thanks everyone in the community for their help in crafting this important policy and for your statements of support or other comments during Last Call. ******** Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2011-1 will expire on 16 November 2011. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-1 ARIN Inter-RIR Transfers Date/version: 14 October 2011 Policy statement: 8.3 Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources may be released to ARIN by the authorized resource holder or another RIR, in whole or in part, for transfer to another specified organizational recipient. Organizations in the ARIN region may receive transferred number resources under RSA if they can demonstrate the need for such resources in the amount which they can justify under current ARIN policies. IPv4 address resources may be transferred to organizations in another RIR's service region if they demonstrate need to their region's RIR, according to that RIR's policies. Inter-regional transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies. Such resources must be transferred in blocks of /24 or larger and will become part of the resource holdings of the recipient RIR. Timetable for implementation: immediate _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info@arin.net if you experience any issues.
In a message written on Wed, Nov 09, 2011 at 03:33:04PM +0000, John Curran wrote:
There is an Draft Policy for Inter-RIR Transfers presently in extended "Last Call" in the ARIN Policy Development Process. The Last Call will run for one more week, and allows an opportunity for anyone in the Internet community to provide feedback regarding this proposed number resource policy. Feedback, including statements in support
I went and read a fair number of PPML messages via the web interface as I no longer subscribe. I also read the policy proposal. I think the AC, and ARIN's policy process in general has come off the rails. There's a reason why I unsubscribed from PPML, and have not participated for 2+ years. I don't know exactly where things went wrong, but somewhere they went very, very wrong. But I don't have to summarize, Bill Sandiford (an AC Member) already did that for me: http://lists.arin.net/pipermail/arin-ppml/2011-November/023661.html Which leads me to my thoughts on the process, from two areas: 1) The concept of Inter-RIR transfers is a bad idea. Insuring "compatible" rules between RIR's will always be difficult at best. There are technical difficulties for the RIR's, such as how reverse DNS is handled. Most importantly, after going through all the pain of figuring out these details it's unlikely to help very many people at all. 2) The process followed to get here is totally broken. Bill hit the nail on the head, and it's archived on ARIN's web site: Text in Sep: http://lists.arin.net/pipermail/arin-ppml/2011-September/023170.html Text in Oct: http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html Near as I can tell the feedback in the October meeting made the AC want to do a _total rewrite of the entire policy_, which they turned around in under a week and shoved directly into the last call process. It's disgusting, and I'm glad I'm no longer involved. It's a mockery of the policy process ARIN has set up, and I'm baffled to this day why more folks aren't upset about it. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Nov 9, 2011, at 10:56 AM, Leo Bicknell wrote:
2) The process followed to get here is totally broken. Bill hit the nail on the head, and it's archived on ARIN's web site: Text in Sep: http://lists.arin.net/pipermail/arin-ppml/2011-September/023170.html Text in Oct: http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html
Near as I can tell the feedback in the October meeting made the AC want to do a _total rewrite of the entire policy_, which they turned around in under a week and shoved directly into the last call process.
Leo - To be clear, the ARIN Advisory Council (ARIN AC) is definitely following the current ARIN policy development process. If they weren't, I would be obligated to directly intervene. It is true that the present Policy Development process allows the AC ample latitude in changing the policy proposals, with the requirement that if the Advisory Council sends a draft policy to last call that is different from the one presented at the public policy meeting, then the Advisory Council will provide an explanation for all changes made to the text. My message to NANOG was to encourage folks to speak out on the PPML mailing list regarding their thoughts on the draft policy, as that is the forum where the input will have the most impact. I will note that ARIN also just completed an open consultation on a revised Policy Development Process, and while it has closed, I will take directly any suggestions that you have for changes to that process that you feel are necessary. Thanks! /John John Curran President and CEO ARIN
1) The concept of Inter-RIR transfers is a bad idea. Insuring "compatible" rules between RIR's will always be difficult at best.
no need to coordinate rules/policies at all. what we suggested in a/p three years back was simple. seller must abide by seller's local selling policy and buyer must abide by buyer's local receiving policy. randy
On Thu, Nov 10, 2011 at 1:01 AM, Randy Bush <randy@psg.com> wrote:
1) The concept of Inter-RIR transfers is a bad idea. Insuring "compatible" rules between RIR's will always be difficult at best.
no need to coordinate rules/policies at all. what we suggested in a/p three years back was simple. seller must abide by seller's local selling policy and buyer must abide by buyer's local receiving policy.
Randy, Such a process creates a back-door requirement that participating registries race to the bottom eliminating eligibility requirements for address recipients. Failure to do so leaves their own registrants at an unfair disadvantage when trying to get addresses. The approach is, unfortunately, more simpleminded than it is simple. But really this discussion belongs on the ARIN PPML where your input would be most welcome. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, 10 Nov 2011 07:39:15 EST, William Herrin said:
Such a process creates a back-door requirement that participating registries race to the bottom eliminating eligibility requirements for address recipients.
When was the last time this industry turned down a chance to have a race to the bottom? </snark>
no need to coordinate rules/policies at all. what we suggested in a/p three years back was simple. seller must abide by seller's local selling policy and buyer must abide by buyer's local receiving policy.
Such a process creates a back-door requirement that participating registries race to the bottom eliminating eligibility requirements for address recipients. Failure to do so leaves their own registrants at an unfair disadvantage when trying to get addresses.
i am sure the americans who think all address space should righfully be theirs can dream up paranoid scenarios for anything. but dear canute, the tide is coming, get over it or get wet. they do not sell enough enough anti-nausea meds here for me to read the arin ppml list. randy
So Randy.. Are you in favor or opposed to 2011-1? Thanks! ----Cathy On Thu, Nov 10, 2011 at 6:28 AM, Randy Bush <randy@psg.com> wrote:
no need to coordinate rules/policies at all. what we suggested in a/p three years back was simple. seller must abide by seller's local selling policy and buyer must abide by buyer's local receiving policy.
Such a process creates a back-door requirement that participating registries race to the bottom eliminating eligibility requirements for address recipients. Failure to do so leaves their own registrants at an unfair disadvantage when trying to get addresses.
i am sure the americans who think all address space should righfully be theirs can dream up paranoid scenarios for anything. but dear canute, the tide is coming, get over it or get wet.
they do not sell enough enough anti-nausea meds here for me to read the arin ppml list.
randy
On Thu, Nov 10, 2011 at 8:28 AM, Randy Bush <randy@psg.com> wrote:
i am sure the americans who think all address space should righfully be theirs can dream up paranoid scenarios for anything. but dear canute, the tide is coming, get over it or get wet.
Randy, You're fortunate that you speak for a minority. If you didn't, we'd tell the bunch of you to go to hell instead of valiantly seeking to improve the situation in which APNIC finds itself.
they do not sell enough enough anti-nausea meds here for me to read the arin ppml list.
It's your privilege to make uneducated snipes from afar. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Bill, On Nov 10, 2011, at 5:48 AM, William Herrin wrote:
On Thu, Nov 10, 2011 at 8:28 AM, Randy Bush <randy@psg.com> wrote:
i am sure the americans who think all address space should righfully be theirs can dream up paranoid scenarios for anything. but dear canute, the tide is coming, get over it or get wet. You're fortunate that you speak for a minority.
I don't think Randy speaks for anyone but himself. Some may, however, agree with him.
If you didn't, we'd tell the bunch of you to go to hell instead of valiantly seeking to improve the situation in which APNIC finds itself.
Seriously? It is this sort of attitude that resulted in me giving up in disgust with the whole RIR circus. Well that and a curious note from ARIN counsel (at the direction of ARIN's board) to my then corporate counsel purportedly "expressing concern" about statements I made in a personal capacity on NANOG. Quite amusing, actually, but still disgusting. A tiny dose of reality: - The Internet (and world population as a whole) is growing most rapidly in the Asia/Pacific region. - There are companies who demand IPv4 addresses for which the combined yearly budgets of all the RIRs amounts to little more than a small fraction of what those companies spend on their lawyers alone. - APNIC no longer has IPv4 addresses to meet that demand. - There now at least 4 different organizations offering IPv4 addresses for sale (addrex.net, kalorama.com, tradeipv4.com, ipv4marketgroup.com) who are now participating in an estimated at $6 - $8 Billion market (and that's just legacy space). And you believe the couple of hundred folks who participate in ARIN are going to stand in the way of those business interests? I might gently suggest it would probably be more useful to figure out how the new market players and the "legacy" RIRs can coexist in a way that doesn't do severe damage to the Internet than it is to discuss how to rearrange the deck chairs in ever more intricate designs in order to try to maintain unjustifiable monopolies. I might suggest that but as I said, I gave up in disgust. Tell King Canute's advisors I said "hi". Regards, -drc
And you believe the couple of hundred folks who participate in ARIN are going to stand in the way of those business interests? I might gently suggest it would probably be more useful to figure out how the new market players and the "legacy" RIRs can coexist in a way that doesn't do severe damage to the Internet than it is to discuss how to rearrange the deck chairs in ever more intricate designs in order to try to maintain unjustifiable monopolies.
arin control-freak vigilante insanity overwhelmed what's good for the internet long ago. randy
On Nov 10, 2011, at 11:59 AM, David Conrad wrote:
A tiny dose of reality: - The Internet (and world population as a whole) is growing most rapidly in the Asia/Pacific region. - There are companies who demand IPv4 addresses for which the combined yearly budgets of all the RIRs amounts to little more than a small fraction of what those companies spend on their lawyers alone. - APNIC no longer has IPv4 addresses to meet that demand. - There now at least 4 different organizations offering IPv4 addresses for sale (addrex.net, kalorama.com, tradeipv4.com, ipv4marketgroup.com) who are now participating in an estimated at $6 - $8 Billion market (and that's just legacy space).
And you believe the couple of hundred folks who participate in ARIN are going to stand in the way of those business interests? I might gently suggest it would probably be more useful to figure out how the new market players and the "legacy" RIRs can coexist in a way that doesn't do severe damage to the Internet than it is to discuss how to rearrange the deck chairs in ever more intricate designs in order to try to maintain unjustifiable monopolies.
David - We've got co-existence today for transfers within the ARIN region; it is now not uncommon to see ("Sale may be subject to compliance with policies of the American Registry of Internet Numbers") on various solicitations involving resources registered in the region. At present, there is no way to transfer resources in or out of the region, and whether that is desirable and under what constraints is precisely the question at hand with draft policy ARIN-2011-1. To the extent that folks have a view on this matter either in support or against, I suggest that you make that view known on the ARIN Public Policy Mailing List (ppml). As this policy will have some effect on many in the Internet community, it would be best for folks to take a moment to provide this important feedback. Thanks! /John John Curran President and CEO ARIN
In a message written on Thu, Nov 10, 2011 at 02:28:50PM +0100, Randy Bush wrote:
i am sure the americans who think all address space should righfully be theirs can dream up paranoid scenarios for anything. but dear canute, the tide is coming, get over it or get wet.
I believe you have made an incorrect assumption as to why some folks are against transfers. Quite frankly, if it made you (and the rest of the world) happier I would support a proposal to reclaim all unused legacy space in the ARIN region and divide 100% of it among the other RIR's. We'd be better off without it. The real problem is, if people spent even 10% of the time spent arguing over how to buy/sell/trade/swap IPv4 space deploying IPv6 space we wouldn't be havng this discussion, as no one would need any more IPv4 space at this point since we would all be removing it from our network. The tide is coming. The tide is wet. The tide is full of IPv6 water. Get over it. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
The real problem is, if people spent even 10% of the time spent arguing over how to buy/sell/trade/swap IPv4 space deploying IPv6 space we wouldn't be havng this discussion, as no one would need any more IPv4 space at this point since we would all be removing it from our network.
The tide is coming. The tide is wet. The tide is full of IPv6 water. Get over it.
i am a measurement type. it's a stretch to call things even slightly damp. not that i am happy with this. we deployed in the '90s. randy
Lucky rich you to have such capacious v4 connectivity to be worrying about such downstream stuff. The rest of the world is starring at abyss of zero connectivity unless it deploys v6. Solve that one. Christian On 11 Nov 2011, at 07:15, Brett Watson wrote:
On Nov 10, 2011, at 6:56 AM, Leo Bicknell wrote:
The tide is coming. The tide is wet. The tide is full of IPv6 water. Get over it.
Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three).
-b
actually - Paul Francis has done the community a massive favor by making the argument for NAT as a viable tool strong enough that NAT and NAT-like technologies are pervasive. NAT is even used to "glue" v4 and v6 enclaves together. So it is too early to tell if IPv6-only will be the inevitable end game (in our lifetimes), or if NAT-enabled infrastructures will continue to be pervasive, leaving v4 enclaves running for longer than our childrens live. This policy proposal is one means to track rights to use a given resource, and it is not clear to me that it has to fit in the sole provence of a single address family (although it is clearly targeted for one of them as currently written) I guess that puts me in the camp of favoring this work. For the rest of the zelots (in either camp) - put down the retoric and quit trying to teach the pigs to sing. Its a waste of your time and it annoys the pigs. /bill On Fri, Nov 11, 2011 at 09:34:27AM +0000, Christian de Larrinaga wrote:
Lucky rich you to have such capacious v4 connectivity to be worrying about such downstream stuff. The rest of the world is starring at abyss of zero connectivity unless it deploys v6.
Solve that one.
Christian
On 11 Nov 2011, at 07:15, Brett Watson wrote:
On Nov 10, 2011, at 6:56 AM, Leo Bicknell wrote:
The tide is coming. The tide is wet. The tide is full of IPv6 water. Get over it.
Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three).
-b
In a message written on Fri, Nov 11, 2011 at 12:15:46AM -0700, Brett Watson wrote:
The tide is coming. The tide is wet. The tide is full of IPv6 water. Get over it.
Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three).
Multi-homing in IPv6 works just like it does in IPv4. Folks may be working on better ways, but that's the reality of the moment, and it's a deployable reality. RA/DHCPv6 is being worked on, and progress is being made...although slower than I would like. But remember, IPv4 isn't done 30+ years on. The IETF has entertained proposals to improve/extend IPv4 every year. NAT wasn't in the original spec. MPLS was added much later, etc. If you expect IPv6 to have 100% feature parity day one and then never change, you have unrealistic expectations. It's deployable today. Heck Comcast is deploying to end-users as we speak. Maybe in a few scenarios it still has significant issues that there are deployment problems, but you find those by doing, not by waiting. The networks I run have been dual stacked for 5+ years. It works. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Fri, Nov 11, 2011 at 06:55:03AM -0800, Leo Bicknell wrote:
The networks I run have been dual stacked for 5+ years. It works.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
and I've been running single-stack IPv6 networks for 4+ years. IVI is a wonderful thing. Dual stack kind of implies you still need IPv4 for -EVERY- node. :) whoops! Guess there is a need for NAT after all, eh? (now promises to stop meing snarky and STFU) /bill
On Nov 11, 2011, at 8:02 AM, bmanning@vacation.karoshi.com wrote:
On Fri, Nov 11, 2011 at 06:55:03AM -0800, Leo Bicknell wrote:
The networks I run have been dual stacked for 5+ years. It works.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
and I've been running single-stack IPv6 networks for 4+ years. IVI is a wonderful thing. Dual stack kind of implies you still need IPv4 for -EVERY- node. :) whoops! Guess there is a need for NAT after all, eh? (now promises to stop meing snarky and STFU)
Dual stack implies that you have IPv4 for some subset of the nodes. It says nothing about need. It says nothing about percentage of the nodes that are dual stacked. Owen
On Fri, 11 Nov 2011 00:15:46 MST, Brett Watson said:
Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three).
What multi-homing issues? We've been multihomed on the IPv6 side for... ages. And yes, there's some RA/DHCP issues - but the *practical* upshot is that it's hard to DHCP a v6-only host and get stuff like DNS and NTP servers to them. So since our users are all dual-stack, we just DCHPv4 the DNS and such to them, and it's not a major issue. If they're on our wireless, they get a globally routable IPv6 address and a NAT-ed IPv4, and DNS and such are available over the IPv4, and mostly everything Just Works (modulo the NAT dain bramage, of course). When we get a good DHCPv6, we'll roll it out.
On 11/11/2011 15:56, Valdis.Kletnieks@vt.edu wrote:
And yes, there's some RA/DHCP issues - but the *practical* upshot is that it's hard to DHCP a v6-only host and get stuff like DNS and NTP servers to them.
another practical upshot is that switch manufacturers now need to support both RA Guard and DHCPv6 snooping instead of just a single protocol like we have in ipv4. That is, unless you're ok with the idea of arbitrary priority RA packets floating around your network. e.g. pages 9-16 of: http://ripe63.ripe.net/presentations/220-ripe63_techteam.pdf Nick
On Fri, 11 Nov 2011 16:04:31 GMT, Nick Hilliard said:
another practical upshot is that switch manufacturers now need to support both RA Guard and DHCPv6 snooping instead of just a single protocol like we have in ipv4. That is, unless you're ok with the idea of arbitrary priority RA packets floating around your network.
When did I ever say I was "OK with the idea"? Our single biggest network security issue is the fact that every day, one or two dozen of our users manage to get phished or hit by a drive-by, have their credentials stolen, and then often get used to send through enough spam to land us on various block lists, at which point the NANOG lurker in the next cubicle has a Bad Day because he's part our e-mail team. Most of the time we catch it, and the user has a Bad Day because they have to deal with the fallout of getting compromised. But this stuff would happen if it was IPv4, IPv6, IPv5.437 or tin-can-and-string. RA Guard is so far down the list of *actual* day to day net operations issues it's not funny. I think the the last time we had to put the smackdown on somebody advertising 2002: was like a year ago. Yes, RA Guard is a consideration. But the subnets we *really* care about are more-or-less physically secure, and the hosts are secure, so we don't see many RA games on critical subnets unless we've *already* got a critical security event in progress. Dorms and the like are easier to RA-spoof - but our switches are all managed, the symptoms of an RA issue are known to our NOC, and when we have an issue, the offending port suddenly loses link. ;) Would it be *nice* to have RA Guard and DHCP6 snooping in place? Yes. Is it totally impossible to deploy IPv6 until they're fully baked? Not at all - just need to be aware of the issues and be prepared to mitigate. Sure it raises the risk level slightly - but we judge the risks of not being well-positioned for IPv6 to be *much* higher.
On 11/11/2011 1:11 PM, Valdis.Kletnieks@vt.edu wrote:
Would it be*nice* to have RA Guard and DHCP6 snooping in place? Yes. Is it totally impossible to deploy IPv6 until they're fully baked? Not at all - just need to be aware of the issues and be prepared to mitigate. Sure it raises the risk level slightly - but we judge the risks of not being well-positioned for IPv6 to be*much* higher.
From a DSLAM perspective, the security stuff was annoying and often just broke IPv6 all together. I am still a fan of 1 vlan per user and q-in-q. It does have issues in dorm type scenarios where you might not want to bring local traffic all the way back to l3 termination, though. Jack
On Wed, Nov 9, 2011 at 10:33 AM, John Curran <jcurran@arin.net> wrote:
The ARIN Advisory Council (AC) met on 14 October 2011 and decided to send an amended version of the following draft policy to an extended last call:
ARIN-2011-1: ARIN Inter-RIR Transfers
Hi folks, There has been some contentious debate about this draft policy. In particular, it may provide a path for bleeding IPv4 addresses from North America to other world regions without requiring reciprocal access to other regions' IPv4 addresses for North American companies. If this concerns you, and I hope it does, I urge you to educate yourself on the matter and then voice your opinion on the ARIN public policy mailing list. Reference materials: The policy as presently drafted: http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html The proposed policy's draft history: https://www.arin.net/policy/proposals/2011_1.html How to subscribe to the ARIN public policy mailing list: http://lists.arin.net/mailman/listinfo/arin-ppml A brief selection of issues raised in the debate: http://lists.arin.net/pipermail/arin-ppml/2011-October/023441.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023464.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023467.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023500.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023511.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023527.html http://lists.arin.net/pipermail/arin-ppml/2011-November/023661.html http://lists.arin.net/pipermail/arin-ppml/2011-November/023667.html Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (13)
-
bmanning＠vacation.karoshi.com -
Brett Watson -
Christian de Larrinaga -
CJ Aronson -
David Conrad -
Jack Bates -
John Curran -
Leo Bicknell -
Nick Hilliard -
Owen DeLong -
Randy Bush -
Valdis.Kletnieks＠vt.edu -
William Herrin