I'm thinking about things like a lawsuit where the plaintiff gets awarded all of the defendant's "assets" in question, and the plaintiff then asks ARIN to transfer the IPv4 defendant's /32 to them. If ARIN simply doesn't transfer /32s, then they can tell the judge "I'm sorry, but we just can't do that, and here's why (point to policy)". Without such a policy, they have to make the much trickier "that's not an asset" argument.
IIUIC, exactly that scenario has happened several times. If so, then I expect that if we get to the point of doing a Staff and Legal assessment on this, they'll bring this up. But regardless of the legal piece, I see no upside, and quite a bit of downside, to allowing IPv4 /32 transfers. I think we need to move the limit, not remove it. -Scott On Wed, Mar 19, 2014 at 11:04 AM, David Huberman < [email protected]> wrote: > Hi Scott, > > > > If I understand your argument - and I'm not sure I do, sorry - you're > saying that it's good to have a policy that SPs can point to and say, "no, > you can't take that /32 we assigned to you with you"? If that's what > you're arguing, then why is a /24 any different than a /32? We see /24s > assigned by SPs to their customers all the time. > > > > Secondly, if this is your argument, why is this not a matter for legal and > contracts, rather than a number registry which is not appointed by the IETF > or NANOG or any other engineering body as the regulator of what size block > is acceptable to regulate? I'm not being flippant and I'm not trying to be > a jerk. I think this kind of reasoning (and 1000 apologies if I > misunderstood your argument) is way outside the purview of ARIN. > > > > Thanks! > > /david > > > > *David R Huberman* > > Microsoft Corporation > > Senior IT/OPS Program Manager (GFS) > > > > *From:* Scott Leibrand [mailto:[email protected]] > *Sent:* Wednesday, March 19, 2014 11:00 AM > *To:* David Huberman > *Cc:* ARIN-PPML List > *Subject:* Re: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block > Size Requirements > > > > I am not speaking in favor of the status quo (a /24 minimum transfer size). > > > > However, IMO having a /32 IPv4 minimum transfer size (no limit) would be a > bad idea. There have been several cases where entities who are completely > ignorant of Internet routing think they have some "right" to a particular > /32, and wish to transfer it. IMO, having *some* minimum transfer size is > a good way to prevent such efforts from being imposed on the rest of us. > (If ARIN can point to policy saying "that simply isn't allowed", they're > in a much better position than trying to argue the particulars of each > case.) > > > > I would have no problem reducing the minimum IPv4 transfer size, just not > all the way to /32. So I oppose the proposal as written, but could support > a revised version. > > > > -Scott > > > > On Wed, Mar 19, 2014 at 10:27 AM, David Huberman < > [email protected]> wrote: > > Hello, > > As the author, I proposed this policy because it is not ARIN's role to > artificially regulate minimum block sizes. I feel this is especially in a > post-exhaustion world, which is very quickly coming. > > The economics of routing are the same today as they were 14 years ago when > Bill Manning taught me an important principal: people will pay to route > whatever you pay them to route. Moreover, there is no technical reason I > can think of to require a /24 as the minimum TRANSFERRABLE size. If two > parties wish to exchange smaller prefixes, I cannot see a technical > motivation for ARIN policy to prohibit such a transaction. > > I ask you to support this policy on principle, or educate us why removing > the minimum transferrable block size is harmful to the technical operations > of the internet. > > /david > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Owen DeLong > Sent: Wednesday, March 19, 2014 9:18 AM > To: ARIN-PPML List > Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size > Requirements > > There has not been a lot of feedback on this proposal. It would be nice to > have more input from a broader cross-section of the community. > > At present, I am leaning towards recommending that we abandon this > proposal for lack of support by the community. If you support this action, > please speak up. If you support this proposal, then it is vital that you > speak up. > > Thank you, > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > > >
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
